feat(reports): render print preview from the same document as the PDF

[Morialkar]

Closes defect (f) from manual QA, and lifts the export memory ceiling.

The problem

The print tab re-implemented the report layout in JSX with its own @media print stylesheet, while the PDF export rendered a Blade template through Dompdf. Two independent implementations of the same document, so they disagreed on markup, on styling, and — least obviously — on content: the preview rendered previewData, which is paginated, while the export ran unpaginated. Printing gave you one page of records; exporting gave you all of them.

The change

renderReportHtml() is now the single rendering of a report document. The PDF export and a new POST /reports/preview/html both go through it. The print tab embeds that document in an iframe and prints the iframe, so what is previewed is what is printed is what is exported — by construction, not by keeping two implementations in step.

This removes ~156 lines of duplicated JSX and the 81-line print stylesheet.

Export limits

Raised, with numbers measured against the real dev report rather than picked round:

	before	after
memory_limit	256M	512M (measured peak 288M)
max_execution_time	30s	180s
nginx fastcgi_read_timeout	60s default	180s

All three were needed: raising memory alone still left the request dying on a timeout.

Verification

Driven against the running stack:

• print tab renders the API document in the iframe: 470 rows, all records, with the PDF's own styling — the old preview showed 10
• selecting a card view switches the preview to 247 cards, 0 table rows, matching what the PDF now produces
• the card export that previously exhausted 256M returns HTTP 200, a 1.5 MB PDF, in 19s
• fresh tab, zero console errors

Also: 185 API tests (2 new — the preview HTML is unpaginated, and it honours the selected card view), 76 client tests (3 new — the iframe carries the API document, print targets the iframe rather than the page, and a failed load reports instead of showing a blank frame), Pint, tsc -b, ESLint, Prettier.

Still open — needs your call

Card mode remains heavy at scale: 248 pages for 247 records, roughly one card per page. That is content, not CSS — the view stacks 16 fields with 12 in a single column and titles that wrap to three lines. I measured removing the column min-height, tightening field margins and card padding, and shrinking the @page margins; none crossed the threshold to two cards per page, so I shipped none of them. Options worth deciding on: cap records per export, offer landscape, or trim the fields in the card view.