feat(viewer): render rich parts server-side, served from /s/:id

[benvinegar]

Problem

Rich parts (markdown/code/diff/terminal/mermaid) intermittently render blank or
clipped on reload under a Chrome 149 field trial. Root cause: opaque-origin
in-memory iframe documents (srcdoc, blob:) defer layout on the affected
profile, so the resize bridge measures 0 and the frame stays collapsed. The
async-rendered parts (diff, mermaid) are hit hardest — they never lay out.

Approach

Keep the opaque-origin isolation; change how the document is produced and
delivered. Rich parts now render server-side and load the same way html
parts already do — from /s/:id?part=N by real URL with a sandbox CSP
response header — instead of an in-memory srcdoc/blob: document. A real
navigation lays out normally on the affected Chrome while staying opaque-origin.

The earlier iterations on this branch (blob: URL, then a POST /api/frames →
/f/:id viewer→server staging round-trip) are superseded: a spike confirmed the
text renderers run on Workers with no DOM/WASM, so there's no reason to render in
the viewer and ship the string back.

• server/richRender.ts renders markdown/code/diff/terminal server-side:
  shiki on the JS regex engine (no oniguruma WASM), @pierre/diffs SSR via
  shiki-js, markdown-it (html:false), ansi_up — all runtime-agnostic, so
  they run on the Worker DO too.
• /s/:id?part=N serves each part under Content-Security-Policy: sandbox allow-scripts. renderSandboxedPart wraps rich bodies under a tighter
  in-doc CSP than html parts: no connect-src, no CDN script source.
• mermaid needs a DOM, so renderMermaidPage emits a self-rendering doc
  that imports mermaid from the CDN inside the sandbox (html-part CSP).
• Versioned + themed /s/:id responses are immutable: long-lived
  Cache-Control plus an in-memory (id,part,version,theme,mode) LRU render
  cache (single-instance DO; swap for KV/Cache API if multi-instance).
• Removes POST /api/frames, GET /f/:id, the transient frame store, and the
  related auth/public-read exceptions. Drops the dead viewer render components,
  highlight.ts, and mermaid/shiki from the client bundle (12.7MB → 86KB).

Why this keeps the security model

The core invariant is untouched: rich frames are opaque-origin via the same
sandbox response header /s/:id relies on — no allow-same-origin, ever.
The rich CSP deliberately allows 'unsafe-inline' (the bridge runs without a
nonce), so the opaque origin is the only thing containing a script — and its
CSP has no connect-src and no CDN/board script source, so even a hypothetical
escaped script could neither phone home nor reach the board. Defense in depth
behind the markdown-it escape.

e2e (isolation.spec.ts): publish a markdown part with an embedded <script>,
assert it's escaped to text, the /s/:id response carries the sandbox header,
window.origin is the opaque "null", the in-doc CSP has no connect-src, and
script-src is 'unsafe-inline' only. mermaid.spec.ts stubs the CDN import to
exercise our loader wiring (render → inject SVG, and the error fallback)
hermetically.

Validation

• npm test — 207/207 pass
• npm run typecheck / lint — pass
• Chromium e2e (rich-part renders, resize bridge, isolation, theme switch,
  mermaid, removed endpoints) — pass
• Verified on real workerd (Durable Object + SqlStore)

🤖 Generated with Claude Code