fix(core): a preview video short of data holds the film instead of looping snippets - #6974

What changes for people

A preview whose video can't get data fast enough used to play about 0.2 s, freeze for half a second, and repeat for as long as it stayed short of data. It now holds the film until it has real data ahead, and it reports that hold as choppy, so an app can switch to a lighter copy.

Four causes, one place (packages/core/src/runtime/init.ts, plus the sync pass in media.ts):

• Holding and resuming sought the starved video onto the film even when it was only about 70 ms late. A seek flushes the decoder and its buffer, which caused the next starve. A video under 0.5 s late now keeps its lag and rate steering closes it; a bigger lag still lands on the film.
• A hold ended on HAVE_FUTURE_DATA, which can mean one frame. It now needs HAVE_ENOUGH_DATA or 1 s buffered ahead.
• The buffered-range reading added for WebKit also answered for Chromium, so the clock ran seconds past a video that was already waiting. It now applies only to WebKit.
• A hold counted as a pause, which had two effects: the playback health window was cleared, so it never read as choppy, and a later clip armed for the next cut was released and reloaded on each hold.

fails without the fix: init.buffering.test.ts, "a video a little behind the film is not sought when it starves or when it resumes", "waits for real data ahead", "the film waits for a playing video stuck waiting, even with the bytes buffered", "a hold for data does not reload a later clip", "a film held for data reads as choppy, so the app can lower it".

What I measured

A real Mac (M-series, 24 GB) running a released desktop build with only the runtime swapped, repo-free fixture: two 4K HEVC clips at 80 Mbps, 120 s film, network throttled to 3 MB/s, one run each, 230 s window.

Before never stepped down because the health window kept clearing. 3 MB/s can only carry about 0.3x of this file, so the speedup is the lighter copy, reached because holds now read as choppy.

The speed is sampled every 10 s. The after run has one dip to 0.74x at 50 s, where the app climbed back to Full, starved and came down. That climb is the app's decision, not this runtime's.

All 2,700+ tests in src/runtime pass, and the new test file passes 3 runs in a row.

What I did NOT exercise

• Safari or WebKit playback. The WebKit branch is covered only by a unit test with a stubbed user agent.
• A slow source that is not network throttled.
• Captures: no Before and After clip attached. This is a timing change, measured in the table above.
• A film starting with a long first load also steps down now, after about 4 s of holding. That follows from the change, and I did not measure it separately.
• On the devbox, 6 tests outside the runtime fail in src/ (index.test.ts, deterministicFonts-aliasSupplement, pageBuild.golden). Load errors in the same run name workspace packages that weren't built there. I did not confirm that for each test; CI is the check.

Size

3 files, about 180 lines added, most of them tests.