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/player/adapters/html5Adapter.test.ts

@@ -192,13 +192,57 @@ describe("Html5PlayerAdapter", () => {
 
     // Allow the internal 100ms settle delay, then fire canplay to resume.
     await new Promise((r) => setTimeout(r, 110));
-    expect(bridge.setSeekOffset).toHaveBeenCalledWith(120);
     expect(bridge.setStreamUrl).toHaveBeenCalledWith("http://new/master.m3u8");
     video._fire("canplay");
+    video._fire("seeked");
     await p;
     expect(video.play).toHaveBeenCalled(); // resumed because it was playing
   });
 
+  /**
+   * The reload lands the viewer at the position they asked for — by *seeking*,
+   * with no transcode offset left over.
+   *
+   * This used to be inverted: the offset was set to the position and nothing
+   * seeked, which was right only while the reloaded URL itself began there via
+   * `StartTimeTicks`. DR-181 removes that parameter, because on an HLS playlist
+   * the server copies it onto every segment URI and then rejects each one with
+   * `400`. With the URL starting at the item's zero, the old arithmetic leaves
+   * `currentTime = offset + 0` — the scrubber reading 20:00 over the opening
+   * titles, and the seek silently never happening.
+   *
+   * TRACES: UR-004, UR-005 | DR-181 | UT-183
+   */
+  it("reloadSource() seeks to the position and clears the transcode offset", async () => {
+    video.paused = false;
+    const p = adapter.reloadSource("http://new/master.m3u8", 1200);
+
+    await new Promise((r) => setTimeout(r, 110));
+    expect(bridge.setSeekOffset).toHaveBeenCalledWith(0);
+    expect(bridge.setSeekOffset).not.toHaveBeenCalledWith(1200);
+
+    // Nothing may seek before the new source is playable — the element drops it.
+    expect(video.currentTime).not.toBe(1200);
+
+    video._fire("canplay");
+    await new Promise((r) => setTimeout(r, 0));
+    expect(video.currentTime).toBe(1200);
+
+    video._fire("seeked");
+    await p;
+    expect(video.play).toHaveBeenCalled();
+  });
+
+  /** A reload to the very start has nothing to seek to; it must not stall. */
+  it("reloadSource() at position 0 does not wait for a seek", async () => {
+    video.paused = false;
+    const p = adapter.reloadSource("http://new/master.m3u8", 0);
+    await new Promise((r) => setTimeout(r, 110));
+    video._fire("canplay");
+    await p; // resolves without any "seeked" event
+    expect(video.play).toHaveBeenCalled();
+  });
+
   /**
    * A reload that never becomes playable must be reported as a failure. It used
    * to resolve on the timeout, so a quality switch whose new stream the server
@@ -227,6 +271,7 @@ describe("Html5PlayerAdapter", () => {
     const p = adapter.reloadSource("http://new/master.m3u8", 30);
     await new Promise((r) => setTimeout(r, 110));
     video._fire("canplay");
+    video._fire("seeked");
     await p;
     expect(video.play).not.toHaveBeenCalled();
   });