Player: five robustness fixes in source setup, seeking and the progress loop

[Nawid3333]

Five small, independent fixes in the player core. Each one is its own commit
and applies to main alone, or with any of the others left out, so any of
them can be dropped. Line numbers are for current main.

What breaks

1. A failed seek preview aborts the video's setup. setSourceInternal()
awaits setupPreviewPlayer() without a catch (FastStreamClient.mjs:948).
If the preview fails to build, the main player is already loading, but
setup skips everything after that line: the video analyzer, the CSS
filters, autoplay, and the timestamp/saved-progress restore. The user also
gets the "send to developer" alert for a video that loads fine.
updateOptions() already treats the same call as optional (:366-368).

2. Seeks outside the video throw away the MP4 buffer. The seek keys
(Comma/Period, Shift+arrows, the arrows) and the skip buttons do
client.currentTime += step. Near either end, that asks for a time outside
the video: Comma (10 s back) at 4 s asks for -6 s. The media element clamps
the seek itself, but the client's setter passes -6 to the state, to the
synced audio player and to the player. MP4Player's setter then asks
whether -6 s is buffered. It never is, so resetHLS() drops the whole MSE
buffer, although the seek lands on 0, which was buffered. The same happens
past the end.

3. Undo/redo leaves the separate audio track behind. undoSeek() and
redoSeek() set this.player.currentTime directly. That skips the client's
setter, which is what also seeks the synced audio player (used with a video
delay). The audio stays at the old position until watcherLoop() resyncs
it, which can take up to about a minute once its resync allowance is used
up.

4. A video that never loaded passes its timestamp to the next one. The
restore at the end of setSourceInternal() waits on this.initPromise,
which resolves when whichever player is current is ready. resetPlayer()
does not clear it. So if source A never loads, A's chain is still waiting
when source B is set, and when B is ready it seeks B to A's
faststream-timestamp.

5. The progress loop can stay stopped. stopProgressLoop() only clears
shouldRunProgressLoop, and the loop notices on its next frame. A
runProgressLoop() before that frame sees isRunningProgressLoop still
true and returns without setting the flag back, so the pending frame stops
the loop. The seek bar then only moves on timeupdate (about 4 Hz). For
example, the next video loads in a background tab: reset() stops the loop,
and the new video's durationChanged() asks it to run again.

The fix

1. The preview build's rejection is caught and logged with
   console.error. When it fails, previewPlayer stays null, as with
   previews turned off.
2. The client's setter ignores NaN and clamps to [0, duration] (only the
   lower bound when the duration is unknown or infinite). MP4Player still
   assigns the raw value to the element, but checks isBuffered() against
   the time the element actually seeks to.
3. Undo/redo go through this.currentTime, with seek saving off, the same
   pattern the other internal seeks use.
4. The restore chain returns if this.source !== source, checked both
   before and after the wait. The check after the wait is the fix. The one
   before it keeps a chain that starts late from setting
   disableProgressSave for the next source, and then leaving it set.
5. runProgressLoop() sets shouldRunProgressLoop = true before the
   isRunningProgressLoop guard.

Diff: 3 files, 31 insertions, 5 deletions.

Why this can't break anything else

1. Only the rejection path changes. A preview that builds runs as before.
2. A value already in [0, duration] passes through unchanged, and the
   element already clamped the rest, so where the video ends up doesn't
   change. Now the state, the audio track and MP4Player's buffer check agree
   with it. A seek to an unbuffered time inside the video still resets.
3. The player gets the same assignment as before. With seek saving off,
   pastSeeks/pastUnseeks end up exactly as before.
4. For a source that is still current, both checks pass. The new source's
   own chain still does its own restore.
5. The guard still prevents a second loop, and a stop with no run after it
   still stops the loop.

Verification

Not run in Chrome or Firefox. A Node script took the real method bodies from
main and from this branch. It ran them against stubbed players, a fake
media element (with spec seek clamping) and a manual animation-frame queue.
For fixes 1 and 4, it ran the real setSource()/setSourceInternal(),
setupInitHook(), the preview build and loadProgressData():

case	main	this branch
1. MP4 with faststream-timestamp=4, preview build rejects	alert, no analyzer, stays at 0	no alert, analyzer set, seeks to 4
2. skip back 10 s at 4 s	state -6, audio -6, buffer reset	0, 0, no reset
2. skip forward 10 s at 158 s of 160	state 168, buffer reset	160, no reset
2. currentTime = NaN	TypeError, state NaN	ignored
2. control: seek to unbuffered 90 s	reset	reset
3. seek 10 → 50, undo, redo	audio seeks [50]	[50, 10, 50], same seek history
4. dead HLS with timestamp 8, then an MP4	MP4 ends at 8	MP4 stays at 0
5. stop + run before the next frame	0 updates in 5 frames	5 updates
5. control: plain stop	stops	stops

• One commit per fix: the script run at each commit changes only that
  commit's rows. Each commit applies to main alone, and the rest apply
  with any one left out (git apply --check).
• Build: npm ci + npm run build: all three targets build.
• Lint: eslint with this repo's .eslintrc.js: no problems.

🤖 Generated with Claude Code