Retagging keeps the xref stream, so Preview opens the output

[bbertucc]

Retagging our own output did a full in-memory save to make the text-check baseline. After that, mupdf wrote the incremental update as a classic xref table carrying the xref stream's trailer (/Type/XRef /W ... /Filter). macOS Preview and PDFKit cannot open that ("failed to find start of cross-reference section"). qpdf and poppler accept it. A user hit it in production.

The baseline is now saved from a second copy of the document. A test retags a file that uses an xref stream and checks that both updates are xref streams. It fails without the fix. On the reported file, the output now opens in PDFKit.

🤖 Generated with Claude Code

[claude]

No blocking issues. All checks pass. The second openPdf(pdf, opts) uses the same options, including any password, so the baseline is built exactly as before. The new test checks the trailing xref type of both updates.

Non-blocking notes

• src/tag.ts:37: save(openPdf(pdf, opts).doc, true) opens and repairs/untags a second full copy of the document and never destroys it. When retagging a large PDF, two mupdf documents now sit in WASM memory until GC finalizes the copy. Calling .destroy() on the copy right after save would release it at once. This is latent: it only matters for big inputs near the memory limit.
• test/document.test.ts:89-93: lastXref only reads the final startxref. That is enough for this regression. It does not check that the update's trailer has no /Type/XRef on a table, but the existing table-path test covers that case only indirectly.

Accessibility impact: none on the tag tree; retagged output now opens in macOS Preview/PDFKit, so users of those readers can reach the tagged document at all.