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/api/repository-client.test.ts

@@ -409,23 +409,26 @@ describe("RepositoryClient", () => {
         handle: "test-handle-123",
         itemId: "item123",
         mediaSourceId: null,
-        startTimeSeconds: null,
         audioStreamIndex: null,
       });
     });
 
+    /**
+     * There is no start-position argument: a position on the HLS playlist makes
+     * the server reject every segment behind it with 400, so resume and seek are
+     * performed by seeking the player after load (DR-181).
+     */
     it("should get video stream URL with options", async () => {
-      const mockUrl = "https://server.com/Videos/item123/stream.mp4?start=300&api_key=token";
+      const mockUrl = "https://server.com/Videos/item123/stream.mp4?api_key=token";
       (invoke as any).mockResolvedValueOnce(mockUrl);
 
-      const url = await client.getVideoStreamUrl("item123", "source456", 300, 0);
+      const url = await client.getVideoStreamUrl("item123", "source456", 0);
 
       expect(url).toBe(mockUrl);
       expect(invoke).toHaveBeenCalledWith("repository_get_video_stream_url", {
         handle: "test-handle-123",
         itemId: "item123",
         mediaSourceId: "source456",
-        startTimeSeconds: 300,
         audioStreamIndex: 0,
       });
     });