Bring PDF report styling closer to the HTML report

[techmore]

Summary

This issue is now mostly about visual parity between browser HTML and exported PDF, not about runtime/report orchestration.

What Is Already Done

• explicit web/PDF stylesheet routing is in place
• saved-scan PDF generation has been moved into the shared reporting path
• several report-pipeline cleanup items that were implicit in this issue have already landed on codex/runtime-contract-fixes

Remaining Work

Track only the parity/design work here:

• align HTML and PDF visual language
• reduce renderer-specific drift
• validate representative outputs side by side
• decide how much print-specific override behavior is still necessary

Recommendation

This issue overlaps strongly with #95 and #96. The cleanest backlog shape is probably one combined report-rendering/parity initiative with smaller follow-up tasks if needed.

[techmore]

Audit note after the codex/runtime-contract-fixes branch: a meaningful portion of the report-generation pipeline cleanup described here has landed already, including explicit web/PDF stylesheet routing and moving saved-scan PDF generation into the shared reporting path.

The remaining work is mostly about visual parity and output quality rather than runtime/report orchestration.

Recommendation: merge this issue conceptually with #95 and #96 into a single report-rendering/parity initiative, then track any remaining implementation details as smaller follow-up issues.

[techmore]

Subsumed by #106.

The remaining work here is now part of the combined report-rendering/parity initiative. The runtime/report orchestration pieces have largely been handled on codex/runtime-contract-fixes; the open work is overlapping rendering-quality and stylesheet-strategy work that is clearer under one umbrella issue.