feat(slides): add Presentation.append_from (slide-CRUD Phase 3 — cross-deck copy)

[MHoroszowski]

Implements Phase 3 of the slide-CRUD epic (issue #11): Presentation.append_from(other_pres, slide_indexes=None) for cross-deck slide copy. Builds on Phase 1 (#33) and Phase 2 (merged via #33) — the two stacked feature branches landed together.

What it does

from pptx import Presentation

target = Presentation("target.pptx")
source = Presentation("source.pptx")
new_slides = target.append_from(source)                        # all slides
new_slides = target.append_from(source, slide_indexes=[2, 0])  # selective + reordered
target.save("merged.pptx")

Returns a list of newly-appended Slide objects in target. Source presentation is unmodified.

Cross-package porting machinery

_PortContext (in parts/slide.py) caches {source_part: target_part} maps for the duration of one append_from call so source slide-master / layout / theme parts shared across multiple appended slides land as a single target part rather than being duplicated.

Per-class porting:

• Slide — deepcopy element + replicate rels minus RT.NOTES_SLIDE, RT.COMMENTS, RT.COMMENT_AUTHORS (Phase 2 policy).
• SlideLayout — deepcopy + remap rels through _replicate_layout_rels; back-rel to ported master; <p:sldLayoutId> registered in target master.
• SlideMaster — deepcopy + walk rels; layouts pre-created and related back to master IMMEDIATELY before the next next_partname call (subtle race where unrelated parts are invisible to iter_parts, allocator hands out the same partname twice).
• Theme — branched on XmlPart vs base Part (binary blob when default content-type isn't registered to a specific XML class).
• Image — routed through Package.get_or_add_image_part(BytesIO(blob)) for SHA1-based dedup at the target package.
• Notes-slide — uses target's existing notes-master (presentation singleton); back-rel rewired to the new slide.
• Chart / OLE / unknown — chart cloned via _duplicate_chart_part_into; OLE / binary via _duplicate_blob_part_into; unknown XML / blob falls through _port_unknown_part (deepcopy element if XmlPart, else blob copy).

OOXML id-collision scrubs (load-bearing)

Two presentations built from the same default.pptx template carry identical id values across their parallel parts. Without scrubbing, the merged file triggered PowerPoint's bad-content / repair dialog on first open. Three classes of collision needed handling on deepcopy:

1. Shared master/layout id pool (per ECMA-376 §19.2.1.34 + §19.2.1.27). <p:sldMasterId id> and <p:sldLayoutId id> consume one identifier space — PowerPoint enforces uniqueness across both. New _used_master_layout_ids_in_target(pres_part) builds a unified pool; _add_sldMasterId_to_presentation and _renumber_sldLayoutIds both allocate from it. Master id consumed first (lowest available), then layout ids above. End state: master2=2147483660, master2's layouts=2147483661..2147483671 — matches PowerPoint's own repair-output ordering exactly.
2. <p:sldLayoutId id> cross-master collision. Source master's deepcopy carries source's layout ids verbatim, identical to target's existing master's layout ids. _renumber_sldLayoutIds reassigns each to a fresh value above the running pool max.
3. <p14:creationId val> on master + every layout. default.pptx ships deterministic vals (master=2209977519, plus 11 fixed layout vals). _refresh_creation_ids rewrites each val to a fresh secrets.randbits(32) while keeping the <p:extLst> structure intact (PowerPoint expects the extension element present).

The diagnostic path that surfaced collision (1): PowerPoint's repair dialog gave only the generic "found a problem with content" with no error-line detail. Iterated by saving the repaired copy and diffing against the original — the rewritten <p:sldMasterId id> value (2147483649 → 2147483660) revealed the master/layout pool sharing.

Tests (37 new in tests/test_append_from.py)

7 describe classes covering API surface, per-slide porting, master/layout/theme port integrity, image dedup invariant, notes-slide round-trip, full save→reopen cycles, anti-criteria (source not mutated, comments dropped, target's existing slides preserved), and OOXMLIntegrity zip-level checks (cross-master <p:sldLayoutId id> uniqueness, master id disjoint from layout id pool, master + layout <p14:creationId val> uniqueness).

features/append-from.feature — 4 acceptance scenarios.

Verification (CLAUDE.md §7)

$ python3 -m pytest tests/ -q | tail -3
........................................................................ [ 97%]
......................................................................   [100%]
3166 passed in 4.54s

$ ruff check src tests | tail -3
All checks passed!

$ python3 -m behave features/ --no-color 2>&1 | tail -3
994 scenarios passed, 0 failed, 0 skipped
2979 steps passed, 0 failed, 0 skipped
Took 0min 1.670s

UAT (CLAUDE.md §6)

uat_append_from.py (untracked at repo root) builds source + target presentations exercising textbox / picture / notes content, cross-package SHA1 image dedup, runs the full append, runs the selective-and-reordered subset variant (slide_indexes=[2, 0]), and round-trips through save→reopen. Maintainer signed off after PowerPoint rendered both _target_out.pptx and _subset_out.pptx clean (no repair dialog) — the post-fix builds.

Refs #11.