Use a dedicated print-first XSL for PDF report generation

[techmore]

Summary

The codebase now supports explicit web/PDF stylesheet routing cleanly. What remains is deciding the long-term PDF stylesheet strategy.

What Is Already Done

• the report pipeline now distinguishes web and PDF stylesheet inputs explicitly
• saved-scan PDF generation uses the shared reporting path
• the runtime no longer depends on the earlier ambiguous report wiring

Remaining Decision

This issue should now focus narrowly on stylesheet strategy:

• keep a dedicated print-first XSL
• rebuild the PDF stylesheet as a thin print override layer
• or converge more strongly on the web stylesheet if parity is the primary goal

Recommendation

If this stays open, keep it narrowly scoped to the stylesheet strategy decision and its implementation.
If not, merge it with #95 and #97 under one report-rendering/parity initiative.

[techmore]

Audit note after the codex/runtime-contract-fixes branch: the runtime/report wiring now cleanly supports distinct web/PDF stylesheet inputs, and the saved-scan PDF path has been moved onto the shared reporting module. That means part of the plumbing implied by this issue is already done.

What remains is a product/design decision about whether to keep a dedicated print-first XSL long-term, rebuild it as a thin override layer, or converge more strongly on the web stylesheet.

Recommendation: consolidate this with #95 and #97 into one report-rendering initiative unless you want to keep this issue narrowly focused on the stylesheet strategy decision.

[techmore]

Subsumed by #106.

What remains here is the broader report-rendering and stylesheet-direction decision, which overlaps directly with the other report-formatting issues. Tracking that work under the combined initiative is clearer than keeping this as a separate parallel issue.