docs: stop serving render masters as if they were deliverables

Thirty-two published videos were the raw render output. One 20-second catalog
preview was 60 MB at 25 Mbps — Blu-ray bitrate for a screen capture in a docs
page. Nothing autoplays, so no page shipped that silently, but a reader who
pressed play paid for it.

Re-encoded at 1280 wide, CRF 28, faststart, keeping audio where it existed.
Measured PSNR against the originals at ~38.5 dB, which is visually identical —
the first check I ran returned nothing and I mistook that for a pass, so this
number comes from a filter that actually worked.

Worth correcting one thing I said earlier: the catalog is not systemically
over-encoded. 190 videos, 0.36 GB, about 1.9 MB each. Six were over 10 MB. I
found two monsters and generalised from them.

Pages carrying more than 8 MB of video: 26 before, and the heaviest went from
140 MB to under 15 MB.

The durable fix is in generate-catalog-previews.ts, which had no delivery encode
at all — it published the render master directly. It has a web pass now, so the
next preview is born small instead of being cleaned up later.

docs/prompting/captions-and-talking-heads.mdx

@@ -17,7 +17,7 @@ Captions route by **identity**, not by mode. You pick one look from the catalog;
 
 <DocsVideo
   title="HyperFrames video: Captions Anchor Rail"
-  src="https://static.heygen.ai/hyperframes-oss/docs/images/prompting/captions-anchor-rail.mp4#t=0.1"
+  src="https://static.heygen.ai/hyperframes-oss/docs/images/prompting/captions-anchor-rail-v2.mp4#t=0.1"
   loop
 />
 *Rendered from the prompt above on generated avatar footage, unedited — one earned embed behind the speaker, everything else on the rail.*