fix(engine): hold the final frame when a video media start is past EOF

[valeriangalliat]

Fixes #3958

What

A non-looping <video> whose data-media-start is at or past the end of the file now renders as a one-frame held tail (the clip's last frame for the whole slot) instead of failing extraction with media_start_out_of_range.

The browser runtime already behaves this way: it clamps currentTime and holds the final frame (isHeldVideoTail), and check passes the composition. Render was the odd one out. The explicit-slot hold from #2516 covers a media start inside the file; this extends it to the degenerate case where zero seconds of source remain, so data-media-start="1.9" and "2.1" on a 2 s file behave the same way.

How

• resolveVideoExtractionWindow: a non-loop past-EOF start returns a finalFrameOnly-shaped window (resolvePastEofHoldWindow) instead of throwing. A source-bounded slot or a slot with no interval inside the composition is skipped, matching the runtime's implicit slot.
• resolveFinalFrameExtractionWindow: sourceRemaining is floored at one logical frame so the held tail never has a zero or negative duration.
• Looping media keeps the typed failure: the runtime wraps the phase there, so there is no single frame to hold. The FFmpeg -ss preflight guard in extractAllVideoFrames and the HDR preflight narrow to the loop case for the same reason.

Tests

• videoFrameExtractor.test.ts: hold at source EOF, hold at video-stream EOF when the container continues, hold well past EOF on a later slot, skip when the slot has no interval in the composition, loop still rejected, end-to-end hold through extractAllVideoFrames.
• captureHdrResources.test.ts: one-frame hold for a non-loop past-EOF start, null for a source-bounded slot, loop still rejected before HDR budgeting.

Repro: https://github.com/ArcadeHQ/hyperframes-repros/tree/patch/media-start-past-eof-hold (check clean, render fails on 0.8.40, passes with this change).