fix(capture): preserve linked PDFs as portable assets

[chubes4]

Summary

Preserve linked PDFs as portable document assets and keep them out of the default adapter's HTML capture queue. Related to #421; extends the document download path introduced in #428.

• Reuse the existing same-origin page-link resolver for raw navigation and rendered header links. Asset links remain in the navigation model but do not become required HTML routes.
• Extend the existing document dependency capture/localization path to .pdf and application/pdf.
• Cover raw and script-created navigation plus byte-preserving portable PDF export, including uppercase extensions and query strings. The existing missing-HTML-route assertions remain intact.

Reproduction and before/after evidence

Source: https://mdhruvil.com/

Published DLA 0.19.4 attempted to navigate /resume.pdf as an HTML page. The endpoint returns HTTP 200 with application/pdf; Chromium's page.goto() throws Download is starting before the non-HTML response check. Four retries for each viewport leave the capture incomplete and block Studio before WordPress materialization.

The default adapter merged navigation/header URLs without using the asset filter already applied to other same-origin links. Separately, the portable document helper and dependency MIME intake supported Word documents but not PDFs.

Fresh candidate capture based on 13711036:

• 6/6 scheduled HTML routes captured, 0 failures (4 distinct routes after trailing-slash deduplication).
• Capture completed in approximately 73 seconds; diagnostics.json reports complete: true, with no capture failures, resource failures, unresolved dependencies, media or anchors.
• capture-receipt.json lists the résumé under assets as website/resume.pdf, not under page routes. The shared header retains a working /resume.pdf link.
• Captured and exported PDF bytes have identical SHA-256: f175f577d2b82e0c4cbcd9086c56f16b190eab0a8cc33181947902dc12bcdd05.
• Capture comparison passed offline self-consistency and all 12/12 baseline cells: four distinct HTML routes at 390, 768 and 1440px, zero pending cells. Baseline scope excludes dialogs, zoom and motion; this is capture-stage evidence, not a solved WordPress/editor claim.

Verification

Regression assertions failed before the fix: raw navigation included the PDF as a required page, and PDF DOM dependency capture fetched no portable bytes. All focused checks pass after the fix:

npm test -- src/adapters/default/discover.test.ts src/lib/screenshot/resource-capture.test.ts src/lib/extraction/sitemap.test.ts src/lib/capture-export.test.ts
# 233 tests passed
npm run build
npm run test:package
# Installed package and relocated runtime workflows passed
node /path/to/worktree/dist/cli.js https://mdhruvil.com/ --output "$PWD/mdhruvil-fixed-source" --screenshots
node /path/to/worktree/dist/cli.js compare "$PWD/mdhruvil-fixed-source/mdhruvil.com" --screenshots

Generated dist/ output was restored after verification, as required by the repository's feature-PR policy.

Execution provenance / AI assistance

OpenAI gpt-6.1-sol via OpenCode investigated the failure, implemented and self-reviewed the source/test changes, ran regression/build/package and real-source capture/comparison checks, and drafted this PR under human direction.

Finalization occurred outside Homeboy after explicit operator authorization. Homeboy's Lab refresh timed out and the documented local Cook route failed admission before coding (mdhruvil-pdf-421-1557137277229211759). Direct work used an isolated Git worktree linked to #421. OpenCode session evidence: ses_eecf4e196ffeOW0yJqoWWWDlif; runtime commands and observed results are recorded above.