fix(player): resume a transcoded video by seeking, not by asking for a stream that starts mid-item

A resumed transcode played nothing at all: every segment came back 400, hls.js
exhausted its retries and gave up, while the same episode from the beginning was
fine.

Jellyfin builds each segment URI by echoing the master playlist's query string
into it, and its segment handler opens by rejecting any request carrying
StartTimeTicks > 0 (ArgumentException → 400). So one resume position on the
playlist is copied onto every hls1/main/N.ts and 400s all of them — the `> 0`
being exactly why starting from the beginning survived.

HLS does not need the parameter: a playlist spans the whole item and asking for
segment N *is* the seek. It is removed from the URL builder entirely rather than
conditionalised — the builder cannot know whether its response will be
segmented — and the position becomes a seek issued once the player has loaded.
The progressive /Audio/universal builder behind the background-audio handoff has
no segments and keeps its StartTimeTicks, which is why audio-only handoffs
resumed correctly and video ones did not.

Completing that across the boundary, since the URL no longer starts where the
caller asked:

- reloadSource(url, position) now means "reload and resume AT this absolute
  position": it seeks the element once the source is playable and clears the
  transcode offset to zero. It previously set the offset to the position and
  seeked nothing, which was correct only while the URL itself began there —
  left in place it would have shown 20:00 on the scrubber while the opening
  titles played, with no seek ever happening.
- The transcoded resume path in the player page collapses into the same
  "seek after load" branch direct streams already used.
- VideoPlayer's background-audio return does the same: no base, seek to the
  absolute position.
- The stale test asserting StartTimeTicks is present is rewritten to keep its
  other half (an HLS master playlist, never a progressive stream.mp4, carrying
  the chosen source and audio track).

TRACES: UR-004, UR-005, UR-019, UR-021, UR-074 | DR-181 | UT-182, UT-183

src/lib/components/player/VideoPlayer.svelte

@@ -1612,14 +1612,19 @@
       // Determine the target URL + how the element/offset should be positioned.
       let targetUrl: string;
       if (needsTranscoding && onSeek) {
-        // Transcoded HLS can't seek by setting currentTime — the stream must be
-        // rebuilt at the new position (StartTimeTicks). onSeek returns that URL.
-        // The reloaded segment's timeline starts at 0, so seekOffset carries the
-        // absolute base and the element seeks to 0 (handled on canplay).
+        // Transcoded HLS is rebuilt rather than seeked in place, but the rebuilt
+        // stream starts at the BEGINNING of the item, not at `pos`: a start
+        // position on an HLS playlist is copied onto every segment URI and
+        // rejected with 400 (DR-181). So there is no base to carry — the element
+        // is seeked to the absolute position on canplay, exactly like a direct
+        // stream. This previously set seekOffset = pos, which paired with a URL
+        // that really did start there; leaving it would now display `pos` while
+        // playing the opening titles.
+        // TRACES: UR-040, UR-004 | DR-181
         targetUrl = await onSeek(pos, selectedAudioTrackIndex ?? undefined);
-        seekOffset = pos;
+        seekOffset = 0;
         currentTime = pos;
-        pendingForegroundSeek = 0;
+        pendingForegroundSeek = pos;
       } else {
         // Direct stream: reload the original URL and seek the element to pos.
         targetUrl = streamUrl;