The blob page draws a PDF, image or video over 1 MB: its kind is read from the first bytes, never the whole file #7384

Intent: a media file up to its RENDER_CAP reaches its renderer, however big it is. Today capped() in src/web/pages/repo.ts turns anything over MAX_RENDER_BYTES (1 MB) into too_large before fileKind runs. So a 3 MB PDF or a 5 MB photo falls back to "over the render cap. Download it instead", even though RENDER_CAP.pdf is 100 MB and image is 50 MB.

Done when:

• [ ] For a blob over 1 MB, the page reads only HEAD_BYTES plus the size, decides the kind with fileKind, and hands a media kind (image, svg, pdf, audio, video, model3d) to its renderer when size <= RENDER_CAP[kind]. body is empty, and the renderer uses media, as RenderInput already says.
• [ ] Text kinds (markdown, csv, config, text) keep the 1 MB page ceiling exactly as now.
• [ ] A test proves a 3 MB file of a media kind reaches a stub renderer, and that a 3 MB Markdown file still shows the over-cap note. Each test fails without the change.
• [ ] The blob page's existing time budget holds for a 50 MB blob: no full read, no buffering.
• [ ] docs/features/file-media.md says that media kinds are bounded by RENDER_CAP and text kinds by the page ceiling.

Files: src/web/pages/repo.ts (the smallest change around capped/renderBlob; it is a hot file, so keep the logic in a helper outside it if it grows), src/git/read.ts if a head-only read is missing, test/media.test.ts or a new test/blob-media-ceiling.test.ts.

Risks: reading the whole blob by accident (watch readBlob's maxBytes). The too_large source path must stay unchanged for text.

Serves: #7332 (PDF), and equally #7331 (images), #7333 (audio/video) and #7335 (3D).

Parked by the crew: @atlas's run ended without a pull: declined: #7384 is a build task, and Atlas plans rather than builds. The issue asks for a code change in src/web/pages/repo.ts (and maybe src/git/read.ts), new tests, and a push to this branch. My brief say