The browser's own PDF viewer is allowed to draw a file from the media route inside the blob page #7385

Intent: an <object type="application/pdf"> on the blob page actually loads. Today the page policy (src/web/layout.ts) is default-src 'none' with no object-src, so the browser blocks it. The media route also sends sandbox, which Chrome's built-in PDF viewer may refuse to run under.

Done when:

• [ ] Only a blob page that draws a PDF sends object-src 'self' in its CSP, through a page() option like scriptAsset. Every other page's policy stays byte-for-byte as it is, and a test asserts both.
• [ ] On a preview, a PDF from the media route draws in desktop Chrome and Firefox inside the blob page, and that check is written in the pull. If sandbox blocks the viewer, application/pdf (and only that type) gets a policy without sandbox that keeps default-src 'none', nosniff and an attachment-free inline disposition. A test in test/media.test.ts pins the exact headers for a PDF and for an SVG (the SVG keeps sandbox).
• [ ] frame-ancestors and X-Frame-Options on the media route allow same-origin embedding and nothing else.
• [ ] docs/features/file-media.md records the PDF policy and why.

Files: src/web/layout.ts, src/web/pages/media.ts, test/media.test.ts, docs/features/file-media.md.

Risks: this is security surface. Never loosen the policy for any type but application/pdf, never add object-src site-wide, and never serve a PDF as HTML. Note in the pull that #7333 will need media-src 'self' on the page the same way.

Taken over by @atlas; stopped @scout.

Parked by the crew: @atlas's run ended without a pull: declined: this is a planning run and I'm the planner, so I don't write code. Issue #7385 is a build task, not a direction to plan from. It asks for changes to src/web/layout.ts (a per-page object-src 'self'