fix(core): the first cut after Play starts on time instead of running ahead - #6794

What

The first cut after Play no longer starts its incoming video too early. Before, that video ran about 50 ms ahead of the playhead for its whole clip: it caught up by holding a frame just after the cut, then reached its last frame early and held it until the next cut. On a short first clip that was one or two dropped frames on every Play from the start.

Why

#6494 starts an upcoming video early by the start delay learned from earlier starts. It also learns from the video that Play itself starts, and that start waits on the playhead's own start as well as the video's. Measured in Studio preview, a start at Play took 64-74 ms against 41-60 ms for a start at a cut. The learned value is an average, so that one sample set the lead for the first cut alone and pulled the next ones up.

Skipping that sample is not enough: with nothing learned, the first cut starts on its tick about 45 ms late, and a late clip catches up by skipping a frame, usually its last one before the next cut.

How

syncRuntimeMedia records whether the playhead was running on the previous call. A video started on a call where it was not (the first tick of playback) counts at half weight; starts at cuts, and starts after a seek during playback, count in full as before. Half is picked from the measurement above, not derived: a cut's delay was 0.55-0.94 of Play's, so half errs late by well under a frame rather than early, and cut samples then take over the average.

Size

Under 100 lines on purpose: one fix to how the first cut after Play learns its start delay, with its test. Every Play from the start drops frames at the first cuts until it lands, and no other open PR touches this code to carry it.

Related work

Refines #6494.

Test plan

• Unit tests: media.test.ts learns half the start delay of a video started by Play. The other start-latency tests now start their first video with the playhead already running, which is the case they describe.
• fails without the fix: counting a Play start in full, or as zero, fails learns half the start delay of a video started by Play and only that test.
• vitest run src/runtime in packages/core: 109 files, 2655 tests passed. oxfmt, oxlint, core tsc and the comment ratchet clean.
• Manual testing in Studio preview, Chrome 156 on an M4 Pro MacBook Pro (macOS 26.5, 120 Hz display), playback started with Studio's Play button, 9 runs per side. Media is one synthetic 44-minute 1080p H.264 file at 23.976 fps with long keyframe gaps (7 s apart on average, up to 10.4 s), cut into a 149-clip edit whose second clip is 0.74 s long. Both sides carry fix(core): long cut-list edits play every cut without dropped or late frames #6785; the measured builds predate its dropped-frame guard, which does not touch starts.

Play at 0 s, 20 s per run, picture timed from each video's requestVideoFrameCallback:

Before, the drops sat at the first two cuts (6.9-7.0 s and 7.6-7.7 s).

An earlier head of this branch skipped the Play sample instead: 4 drops in 9 runs, the first cut's first frame 64 ms late (median), and a lost last frame in 6 of 9 runs. Half weight removes all three.

With Play at 64 s, where Play itself starts the video under the playhead, the 1-3 drops within 2 s of Play are not this change's: 9 runs interleaved run by run with the previous head, 19 → 16.

For scale: one plain <video> playing the same file on the same machine drops 1-2 frames a minute, and started mid-file it held one frame in its first second in 2 of 9 runs.

• Documentation updated (not applicable)
• Comments follow CONTRIBUTING.md "Comments"