rpptx Python bindings: what is left for a production deck chain, as one checklist

[hadim]

Thanks for #141 to #145: on main at 9a7ed714 I can open a real deck exported from Google Slides, edit runs, paragraphs,
text frames, geometry, fills, lines, pictures, notes and slide visibility, add shapes and connectors,
save, validate, reopen it in python-pptx and render it, all from Python; text_layout() gives the same
line count as my own wrap model on every text frame of the deck, which lets me drop that model. What
remains, in one list rather than one ticket per bench:

Exists in Rust, not bound

• Presentation::duplicate_slide (rpptx/src/lib.rs:2460); accept: prs.slides.duplicate(slide)
  returns the new slide, notes included.
• Presentation::from_bytes (lib.rs:889), as rdocx has.
• replace_text / try_replace_text (lib.rs:1795, 1823), with the expected-count contract of the CLI
  (rpptx replace --expect, rpptx: to_notes_pdf() requires a relationship from the notes slide to its slide; rpptx replace overwrites its output and skips notes #120); accept: a count mismatch raises and leaves the presentation unchanged.
• resolve_comment and remove_comment (lib.rs:2094, 2121): Python has list, add, reply and move;
  the CLI has list, add, reply, resolve and remove. Both methods were added to the facade for the CLI in
  rpptx CLI: no --json on text and outline, no speaker notes in either, and no comment subcommand #145 (PR rpptx CLI: JSON text and outline, speaker notes and comment commands #151); the binding did not follow.
• validate (lib.rs:1550), returning the issues the CLI prints.
• Table cells: TableCellMut::merge_to / split (lib.rs:6627, 6639), set_fill (6569),
  set_margins (6579); Python has cell.text and column widths only.
• Inherited placeholder geometry: on a placeholder without its own a:xfrm, the normal case in a deck
  made in PowerPoint, left, top, width and height return None, where python-pptx returns the
  layout's values; the renderer already resolves them (effective_xfrm, rpptx-layout/src/context.rs:234).
  Setting left alone then writes an a:xfrm with y="0" and no a:ext, as python-pptx also does;
  python-pptx then reads the layout's width and height, rpptx None. On the umbrella's deck fixture
  (Production readiness for editing real docx and pptx files: an acceptance contract, two realistic fixtures and two matrices #158), the title of slide 2 gives (None, None, None, None) in rpptx and (457200, 274638, 8229600, 1143000) in python-pptx. None follows the explicit-values rule recorded in PR Python: rpptx text frame, paragraph and run formatting #149 (and pinned for
  inspect --json in PR rpptx CLI: JSON text and outline, speaker notes and comment commands #151), and I do not ask to change that rule; Python bindings for rpptx, round 1 on the presentation side: expose what the reader and the resolver already know about a slide #141 asked for the properties that
  still differ from python-pptx, and this is one. accept: an accessor for the effective geometry (for
  example shape.effective_geometry()), or geometry as an exception to the rule since the renderer
  already resolves it; and setting one coordinate materialises the other three from the effective
  geometry.

Not found in Rust, or modelled without a public API

• Table rows and columns: add, remove, row height, cell borders.
• Z-order: bring a shape forward or backward (new shapes are appended on top).
• Picture crop (a:srcRect): modelled as BlipFill.source_rect (oxml-drawing/src/fill.rs:844),
  with no public setter.
• Changing the layout a slide uses.
• Hyperlinks on runs and shapes, read and write: the run's is modelled as hyperlink_click
  (oxml-drawing/src/text/paragraph.rs:599), which holds only the relationship id: it can be read and
  replaced through TextRunMut::properties() / set_properties(), but nothing public resolves, adds or
  retargets the hyperlink relationship.
• Comments anchored on a shape or a text range rather than on the slide.
• Built-in table styles: a table whose a:tableStyleId names one of PowerPoint's built-in styles
  without the package defining it (python-pptx writes every table that way) renders unstyled; the layout
  looks styles up in ppt/tableStyles.xml only (rpptx-layout/src/context.rs:2160). LibreOffice applies
  the built-in definition. Saying this is out of scope is a fine answer.

Setting Run.text invalidating every handle is filed separately.

If any of these is out of scope by design, a word saying so lets me keep a thin python-pptx step for it.

Environment: main at 9a7ed714 (S75), release build, linux x86_64, Python 3.11.