fix(core): replay ended audio after backward seeks

[jrusso1020]

What

Recover ended non-looping audio after a real backward timeline seek or true clip re-entry, including short clips whose native media element is still near EOF.

This PR covers the Studio/player replay half of the Framey audio investigation. The independent offline-render timestamp fix is already in #3380.

Why

After a short audio element reached native EOF, the runtime rejected it in the active gate before it could rewind currentTime and call play(). Seeking the Studio timeline back to the beginning therefore made short lines such as “who?” and “really?” deterministically silent once their elements entered the browser's ended state.

A broad ended-audio recovery would introduce a second bug: native EOF can lead the runtime clock by a few milliseconds, and ordinary play/pause or rate-change force-sync ticks must not replay that tail.

How

• Track each element's previous desired source time separately from drift state.
• Admit ended audio only on true first activation or a meaningful backward desired-time transition.
• Rewind stale forward audio on the first active tick at the normal strict-drift threshold, without forcing cold/buffering audio forward.
• Preserve the desired-time baseline while native EOF remains inside the authored window so later polling ticks cannot become false re-entries.
• Keep existing non-looping video held-tail behavior unchanged.

Test plan

• Unit tests added/updated
• Manual post-fix Studio testing performed
• Documentation updated (not applicable; runtime-only bug fix)

Added regressions for:

• ended audio re-entering at clip start
• backward seeks within the active clip
• multiple native-EOF ticks with forceSync
• desired time beyond source duration
• stale short audio on re-entry
• cold/buffering audio that must not be forced forward

Verified locally:

• Core suite: 121 files, 2,437 tests passed
• Focused media runtime: 105 tests passed
• Core typecheck passed
• Packaged runtime behavior and seek checks passed
• oxlint, oxfmt, git diff check, and pre-commit hooks passed

Companion renderer fix: #3380.

[miguel-heygen]

Reviewed exact head b28de8cc43614d92ccda3967fba1e3e4d90f90cf.

The recovery gate is narrow enough to fix backward transport without turning ordinary EOF into a loop:

• media.ts:243-256 admits ended audio only when it is non-looping, has a known playable source window, is inside that source, and either has no prior desired-time baseline (true activation) or moves backward by more than the strict 40 ms threshold.
• media.ts:491-499 preserves only desired source time while native EOF is still inside the authored window, so repeated EOF/force-sync ticks cannot manufacture a fresh activation; a real outside-window transition and evictMediaSyncState still clear every baseline for true re-entry/source swap.
• media.ts:383-393 rewinds stale short audio only when the native element is ahead on its first active tick, while cold/buffering audio at zero is not forced forward. The non-looping video held-tail/backward-seek behavior remains structurally unchanged.

The regressions distinguish ended re-entry, within-window backward seek, repeated EOF force-sync ticks, past-source time, stale-forward re-entry, and cold audio. All required checks are green at this exact head, including Linux + Windows tests, runtime contract, build, typecheck, Windows render, and regression.

Verdict: APPROVE
Reasoning: The new desired-time baseline separates actual backward transport from EOF and transition ticks, closes the silent short-audio replay failure, and preserves existing video/tail semantics with direct edge-case coverage.

— Magi