fix(engine): local renders lay out width-only videos like the browser - #5771

What changed

A local hyperframes render drew a <video> that the page sizes with only a CSS width (or only a height, or only a max-width) in the wrong box. A 200px-wide 16:9 clip got a 200x360 box with the picture centred inside it, so it sat lower than in the browser preview and in distributed chunk renders, which draw it at 200x112.

Cause: local renders pass the probed size of every extracted video to the engine, and applyVideoMetadataHints wrote it as width/height attributes. Those attributes are CSS size hints, so whichever axis the page left unset took the hinted pixel value instead of following the video's shape.

The hint exists for videos whose metadata Chrome never loads (frames are injected, so Chrome would otherwise lay them out at 300x150). It now gives such a video a transparent SVG poster of the probed size instead. Chrome takes a video's natural size from its poster until the video's own metadata loads, so every CSS combination lays out exactly as it does with the real video. The explicit aspect-ratio fallback is gone for the same reason. A video that already has a poster is left alone.

contain: size + contain-intrinsic-size was tried first and rejected: it matches the simple cases but shrinks a bordered width:100% flex item (style-9-prod's layout) by the border width.

What I measured

• New real-Chrome test frameCapture-videoMetadataHints.browser.test.ts: six 640x360 videos with no metadata (no size, width only, height only, both sizes with object-fit, max-width only, bordered flex item) must get the boxes Chrome gives the same markup once a real 640x360 video's metadata has loaded (measured separately: 640x360, 200x112.5, 160x90, 200x300, 100x56.25, 416x241).
  • On origin/main (with only the export added) it fails: width only 200x360, height only 400x90, max-width only 100x360, bordered flex item 416x376.
  • With the fix: passes 3 runs in a row. Mutation (contain-size approach instead of the poster): fails on no size and the bordered flex item.
• frameCapture.test.ts: 55 passed. Engine typecheck, oxlint and oxfmt clean.
• Render of a two-video page (width-only and height-only clips): before, the local frame put both clips in the wrong box; after, the local frame and a distributed chunk frame show the same layout (PSNR 50 dB, the encoder difference only).
• Every producer regression fixture with a video (28): loaded each output/compiled.html in headless Chrome and compared every video's box with old hints, new hints and no hints, with media loading and with media blocked. With media loading, old and new give the same box in all 28, so no baseline should move. With media blocked, new matches the loaded box in all 28; old was off for style-9-prod (1920x1087 instead of 1936x1096).
• Producer regression harness (Docker test image built from this branch) on the video-layout fixtures: render-video-overlay-stretch, style-9-prod, portrait-edge-bleed, sub-composition-video, pip-video-late-host, video-hfid-no-id, style-4-prod: 7 of 7 passed against the committed baselines. No baseline changed.

What I did NOT exercise

• A video that already has an authored poster keeps that poster, so if its metadata never loads it lays out at the poster's shape (same as in a browser before the video loads).
• The test cannot observe the wait for the poster to decode: Chrome had applied the poster by the next CDP call even without it. A same-task probe showed the box is still 300x150 straight after setting the poster and correct after the decode, which is why the wait stays.
• Windows and macOS renders; the full regression suite (only the video fixtures listed above ran).