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/routes/player/[id]/+page.svelte

@@ -334,22 +334,20 @@
               : `loadAndPlay: Using stream URL: ${streamUrl}`
           );
 
-          // Set initial position for video player to seek to after load
-          // Use explicit startPosition, or fall back to retrieved progress from database
-          // For transcoded content, we need to request a new stream with StartTimeTicks
+          // Set initial position for the video player to seek to after load.
+          // Use explicit startPosition, or fall back to retrieved progress.
+          //
+          // Transcoded streams resume the same way direct ones do — by seeking
+          // after load. Asking the server for a stream that *starts* at the
+          // position is what DR-181 removed: on an HLS playlist that position is
+          // copied onto every segment URI and the server then rejects each one
+          // with 400, so a resumed episode played nothing at all while the same
+          // episode from the beginning was fine.
+          // TRACES: UR-004, UR-019 | DR-181
           const effectivePosition = startPosition ?? retrievedProgressSeconds ?? 0;
-          if (effectivePosition > 0) {
-            if (videoNeedsTranscoding) {
-              // For transcoded streams, get a new URL starting at the position
-              console.log("loadAndPlay: Getting transcoded stream starting at:", effectivePosition);
-              streamUrl = await repo.getVideoStreamUrl(id, mediaSourceId ?? undefined, effectivePosition);
-            } else {
-              // For direct streams, we'll seek after load
-              videoInitialPosition = effectivePosition;
-              console.log("loadAndPlay: Will seek to position after load:", videoInitialPosition);
-            }
-          } else {
-            videoInitialPosition = 0;
+          videoInitialPosition = effectivePosition > 0 ? effectivePosition : 0;
+          if (videoInitialPosition > 0) {
+            console.log("loadAndPlay: Will seek to position after load:", videoInitialPosition);
           }
         } else {
           // For audio, use MPV backend
@@ -531,14 +529,22 @@
   }
 
   /**
-   * Handle video seeking by requesting a new stream URL starting at the given position.
-   * Transcoded streams don't support native seeking, so we restart from a new position.
+   * Rebuild the stream for a transcoded seek or an audio-track switch.
+   *
+   * The returned URL starts at the beginning of the item, not at
+   * `positionSeconds`: a start position on an HLS playlist is copied onto every
+   * segment URI and rejected with 400 (DR-181). The caller seeks the reloaded
+   * element to the position — `positionSeconds` is kept in the signature because
+   * VideoPlayer's seek contract passes it, and the audio-track switch needs the
+   * same rebuild.
+   *
+   * TRACES: UR-004, UR-005, UR-021 | DR-181
    */
-  async function handleVideoSeek(positionSeconds: number, audioStreamIndex?: number): Promise<string> {
+  async function handleVideoSeek(_positionSeconds: number, audioStreamIndex?: number): Promise<string> {
     const repo = auth.getRepository();
     const id = itemId;
     if (!id) throw new Error("No item ID");
-    return repo.getVideoStreamUrl(id, mediaSourceId ?? undefined, positionSeconds, audioStreamIndex);
+    return repo.getVideoStreamUrl(id, mediaSourceId ?? undefined, audioStreamIndex);
   }
 
   // Playback reporting callbacks