Captions from the previous media aren't cleared when loading a file from Recents

[maboa]

Loading a file from Recents doesn't clear the previously-loaded media's captions. The new file's captions render, but the old caption track is still shown too — two caption sets stacked over the video.

Repro (see screenshot):

1. Start with the default intro media (captions present).
2. Load a different file from Recents.
3. The video shows the new file's captions and a leftover caption from the intro media at the same time.

Expected: loading new media (via Recents, or any media swap) clears the old captions/VTT cues so only the current file's captions display.

Likely area: on load the caption <track id="hyperplayer-vtt"> / video.textTracks cues aren't reset — the previous file's cues persist alongside the regenerated ones. The Recents path wipes .transcript-holder and re-inits, but the caption track on #hyperplayer isn't cleared/rebuilt cleanly.

Possibly related: the doubling-up of captions from a single video when clicking around the transcript — likely the same root cause (stale/duplicate tracks or cues). See #287 ("Occasionally two sets of captions are shown contemporarily"); this may be a dupe or sibling of it.

Notes: Chrome/Safari priority.

[maboa]

The transcribe-path recurrence of this — a newly transcribed clip showing the previous clip's captions superimposed on the new ones — was fully fixed in v0.8.9 (PR #424).

Root cause was two-part, which is why earlier fixes only partially resolved it:

1. Old cue data. The reused <track> element kept the previous transcript's cues; captions are now reset (resetCaptionTrack) on regenerate, not only on Recents load.
2. Old cue pixels. On a paused video the browser doesn't re-composite its native caption overlay, so the previous cue stayed painted even after the track was swapped. The overlay is now forced to repaint (track display-mode toggle) to flush the stale ::cue paint.

Covered by an e2e regression test (__TEST__/e2e/caption-track-reset.spec.mjs).