fix(core): skip a video the browser can't decode instead of freezing the film - #7355

What

A video the browser stopped loading after its header no longer freezes the whole film in preview. The runtime now skips such a clip, plays the rest, and logs one console.warn naming it.

A clip counts when, 5 s after it was first asked to play, it is still at HAVE_METADATA with networkState NETWORK_IDLE and has never had a frame of its current source. A clip that is still loading (NETWORK_LOADING) never skips, however long it takes. A clip whose play() the browser refused (NotAllowedError, waiting for a tap) never skips either: each refusal restarts its 5 s.

Why

On iOS Safari (iPhone 17 Simulator, iOS 26.5), a film with VP9 WebM clips never played: the playhead stopped at about 0.04 s and stayed. That Safari answers "" for video/webm; codecs="vp9", yet with a plain src it reads each WebM's header (480 px wide, no error), sets networkState to idle and never delivers a frame. The runtime only treated an element as unplayable on an error or NETWORK_NO_SOURCE, so it waited on those clips forever and held the whole film.

A typed <source> the browser rejects is already dropped by the browser (NETWORK_NO_SOURCE), so it needed no change. The gap is a source with no type: canPlayType("video/webm") answers "maybe" there, so the file type alone can't tell.

How

• isUnplayable in packages/core/src/runtime/media.ts, the check every playable-or-not decision routes through (the transport's buffering hold, the play() guard, the iOS tap priming), adds the header case and warns once per element.
• markPlayRequested records when an element was first asked to play; loadeddata marks it as having had a frame and emptied (a new source) resets it. A NotAllowedError from play() forgets the ask, so a clip waiting for a tap keeps being primed and retried as on main.
• Render mode is untouched: the render path doesn't ask elements to play.

Test plan

• Unit tests added in play() storm guard (unplayable elements), all on fake timers:
  • skips a clip whose fetch stopped at its header 5 s after it was asked to play: not at 4999 ms, yes at 5000 ms, one warning naming the clip.
  • keeps waiting on a clip still loading at its header 5 s after it was asked to play: 60 s, no skip, no warning.
  • keeps waiting on a clip at its header whose play() the browser refused: a NotAllowedError, then 5 s, no skip, no warning.
• Fails without the fix: with isUnplayable reduced to main's rule, the header test fails; with the NETWORK_IDLE condition removed, the still-loading test fails; with the refusal reset removed, the refused-play test fails.
• media.test.ts and mediaProxy.test.ts pass 3 runs in a row; the whole src/runtime suite (120 files, 2861 tests) passes on Linux; core tsc --noEmit clean.
• iPhone 17 Simulator (iOS 26.5), the player perf bench's heavy-alpha-webm film, 3 plays at the first head: before, the playhead held at 0.03 to 0.07 s in every play; after, it reaches 10.0 of 10.0 s each time, with one skip warning per WebM clip. The later change only adds the refusal reset (the Simulator run allows autoplay, so no play() was refused) and removes a branch that never fired there; the Simulator run was not repeated.

The film still waits 5 s at each start where such a clip falls due (here at 0 s and about 3 s) before skipping it.

Size

Small on purpose: one shared check gains one case, the play() rejection handler resets it on a refusal, and three tests.

Size: a lone fix. A video the browser cannot decode freezes the whole film, and no open PR in the player can carry it.