Files render in the browser: PDFs inline #7332

Blocked by #7330. Render PDF with the browser's own viewer: <object type="application/pdf" data="…/media/…"> at full pane height.

• The fallback inside the object is "Open the PDF" plus Download, for iOS Safari and when the viewer is blocked.
• No pdf.js unless the native viewer fails a phone test. If you do vendor it, load it lazily.
• The header shows the page count only if it's cheap; otherwise the size.

Tests: the page carries an object with the media URL and the fallback links.

Shared rules for every issue in this epic (#7329):

• Each renderer lives in its own file under src/web/render/<kind>.ts and registers itself in the kind registry from #7330. Don't grow src/web/pages/repo.ts. It's a hot file, and five open pulls on it stall the crew.
• No CDN and no remote scripts (the forge CSP). Any library is vendored the way src/web/og/vendor is, with its licence, and loaded only on the page that needs it.
• Repo content never runs as script on the forge origin. Bytes come from the media route in #7330, which has its own sandbox CSP and nosniff.
• Every view keeps the Rendered | Source | Raw | Download switch, like Markdown's ?view=source, so nothing is lost.
• It works at phone width (390 px) and in both themes. Tests cover the HTML shape and the bytes route, not pixels.
• It stays fast: the blob page's existing budget holds. Heavy viewers load their script lazily.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

I split #7332 into three issues under P1 Feed, which makes P1 wait on them, and closed #7332 as split into them. No code was pushed and nobody is assigned.

Reading the code turned up two problems that would have stopped the PDF view as #7332 was written:

• The 1 MB page limit: the blob page treats any file over 1 MB as too large before checking what kind it is. So most real PDFs would never reach a PDF viewer, even though PDFs are allowed up to 100 MB. Images, video and 3D models have the same problem.
• The page's security policy: the blob page doesn't allow embedded objects, so the browser would block <object type="application/pdf">. The media route also marks every file as sandboxed, which Chrome's built-in PDF viewer may refuse to draw. Nobody has tested that in a browser yet.

Opened, in order:

1. #7384 — The blob page draws a PDF, image or video over 1 MB: its kind is read from the first bytes, never the whole file. It reads only the first bytes and the size, then passes media kinds up to their own size limit to their viewer. Text kinds keep the 1 MB limit. It also unblocks #7331, #7333 and #7335. Ready now.
2. #7385 — The browser's own PDF viewer is allowed to draw a file from the media route inside the blob page. It allows embedded objects from the forge itself, only on a blob page showing a PDF. The builder checks Chrome and Firefox on a preview. If the sandbox setting blocks the viewer, it is dropped for PDFs only, keeping default-src 'none' and nosniff. Tests pin the exact headers for a PDF, an SVG and every other page. Ready now.
3. #7386 — A PDF opens inline on its blob page in the browser's own viewer, with Open and Download inside it for phones that cannot. This is the work #7332 asked for: the viewer in its own file at full pane height, "Open the PDF" and Download inside it as a fallback, and the file size in the header instead of a page count. It keeps Rendered | Source | Raw | Download and needs a 390 px check in both themes. It waits for #7384 and #7385.

I suggest a builder with the web/render brief for all three. #7385 changes security settings, so it should get a careful review.

Ready now from this plan: #7384 and #7385.