fix(producer): extract HDR video frames a window at a time to bound scratch disk - #6304

A long HDR clip no longer needs the whole clip's raw frames on disk at once, so a 5 minute HLG video renders instead of stopping at the disk-space check.

Cause: extractHdrVideoFrames wrote every frame of each HDR video as raw 16-bit RGB before the first frame was captured: 6 bytes per pixel per frame. 5 minutes at 30 fps and 1080p is 9000 frames x 12.4 MB = 112 GB. The headroom check then refuses it (draft quality changes nothing, extraction does not depend on it).

Fix: each video is cut into windows of about 512 MB (43 frames at 1080p). A window is extracted with one FFmpeg pass when the capture first reaches a frame in it, the next one starts half way through, and least-recently-used windows are deleted once more than workers + 1 exist. Scratch disk is that bound, not the clip length. Frames are read through a lease that pins a window while a frame is read, so parallel capture workers cannot evict each other's window.

Frame accuracy: every window runs on the clip's own tick grid. The seek lands on a whole second before the window, fps is pinned to the clip's first frame offset (probed once), and the lead-in frames are trimmed. Checked against the old whole-file pass byte by byte at every frame, window boundaries included, on a 5 minute 10-bit HLG clip (mediaStart 3.37 and 0, 43-frame windows) and a 24 fps clip (three start offsets): 0 mismatches of about 1200 frames each. The naive per-window seek is wrong on 24 to 30 fps (478 of 1199 frames), which is why the grid is pinned.

One behaviour change: a variable frame rate source now maps each output frame to the nearest source frame. The old pass (-r) carried timing drift from earlier frames that a window cannot replay (171 of 1200 frames in the VFR fixture differed, always the neighbouring source frame). The windowed output is identical between windows and a single whole-file pass.

Measured on a 1080p 10-bit HLG clip, draft render, peak extra disk during the render:

• 30 s: 11.3 GB before, 2.2 GB after; output MP4 byte-identical. Wall time 3m 13.8s on main vs 3m 12.6s windowed on the final build (same devbox, one run each; an earlier windowed run with prefetch took 2m 36.4s on a quieter box), so the window path is not slower. The 60 s old path was not run: it needs 22 GB of scratch and the shared devbox cannot spare it.
• 60 s: 22.3 GB before, 2.6 GB total after (1.8 GB in scratch dirs); windowed render 5m 37.6s.
• 5 min (the reported case, 112 GB before): renders to completion, 9000 frames, 300.0 s, 10-bit HLG, peak 3.3 GB total (2.9 GB in scratch dirs).

Tests: window store (extract on demand, bounded resident windows, a leased window is not evicted, short source and end-at-boundary hold the last frame, failed extraction retries, close removes files), the FFmpeg arguments, and a long clip held in at most two windows. The two bound tests fail with eviction disabled. 50 tests pass three runs in a row.

Package size: producer packed budget raised by 2389 bytes (768601 to 770990), exactly this change's measured delta on a linux pack against current main; the bytes buy HDR scratch of 112 GB down to about 3 GB for a 5 minute clip. The code lands in both producer bundles; prefetch of the next window was left out because the 5 min render was 29m 17s with it and 30m 01s without.

Stands alone.