feat(pptx): view issues renderer-approximation audit (textWarp/textFill)

[ylz92871-dotcom]

What

Extends view issues for pptx with a renderer-approximation audit: two new issue subtypes surface text effects that are stored correctly in the OOXML but that the HTML/SVG preview can only approximate, so a deck that "validates clean" no longer silently screens wrong:

• text_warp_renderer_approximated (Info) — a textWarp preset is only marked in the preview; it cannot warp individual glyphs like PowerPoint does.
• text_fill_renderer_approximated (Warning) — a run's text fill is an image (blip) fill, a path gradient, or a gradient with 3+ stops — the forms the CSS preview path reduces to a single color.

Faithfully-rendered cases stay silent: no explicit fill, un-transformed solid, or a simple two-stop un-transformed linear gradient. One report per shape (mirrors the LowContrast policy).

Why

The document and the preview disagree in one direction only: the OOXML is correct (PowerPoint renders the gradient/warp), but the agent's HTML preview shows a solid/straight approximation. That is the silent-acceptance gap — an agent shipping a deck from preview feedback believes the delivered look is verified when it is not. Surfacing the gap in view issues makes it observable and actionable ("run a screenshot to confirm the delivered look") without flagging anything actually wrong in the file.

How to verify

officecli create demo.pptx
officecli add demo.pptx / --type slide
officecli add demo.pptx /slide[1] --type shape --prop "text=Warped Title"
officecli set demo.pptx "/slide[1]/shape[1]" --prop "textWarp=textArchUp"
officecli set demo.pptx "/slide[1]/shape[1]" --prop "textFill=FF0000@0-00FF00@50-0000FF@100"
officecli view demo.pptx issues
officecli close demo.pptx

Actual terminal output:

Found 2 issue(s):

Format Issues (2):
  [W1] /slide[1]/shape[@id=100000]: Text warp 'textArchUp' is only marked in the preview — the HTML preview cannot warp glyphs like PowerPoint.
       Suggestion: PowerPoint renders the true warp; the preview shows only a text-warp marker class.
  [T2] /slide[1]/shape[@id=100000]: Gradient text fill with 3 stops — the preview shows a solid approximation.
       Suggestion: The stored OOXML is correct and PowerPoint will render it; run a screenshot to confirm the delivered look.

A plain solid-fill shape with no warp reports neither (no false positives on the common case).

Implementation

• src/officecli/Handlers/Pptx/PowerPointHandler.View.cs — per-shape audit in the existing issues walk: GetTextWarpApproximation (reads bodyPr/prstTxWarp @prst, null for absent/textNoShape) and TextFillApproximationReason (blip fill / path gradient / >2 stops), each emitting a DocumentIssue with the existing subtype/validation machinery.
• src/officecli/Core/IssueSubtypes.cs — the two new subtypes + ValidSubtypes registration, so view issues --type text_fill_renderer_approximated opt-in filtering works like every other subtype.

Tests

• dotnet build -c Release — 0 errors.
• XLSX numeric-fit regression suite (local repo-untracked harness per the maintainer's local-only test policy) — green.
• dotnet publish -c Release — single-file exe smoke OK; the demo above was produced with the built binary.