fix(player): change the audio track, and load subtitles at all

Two faults, both present since v0.0.1, both found and confirmed on a device.

Audio track (DR-258). Jellyfin builds a transcode around one AudioStreamIndex,
so the alternate tracks are not in the stream that arrives — but the native
path only ever called setAudioTrack(n), which indexes ExoPlayer's audio track
*groups*. On Android that is the common case, since any source whose default
audio codec the device cannot decode is transcoded: logcat showed ExoPlayer
holding `Audio tracks: 1` while the menu listed every track in the file, so
each selection warned `Invalid audio track index` and was dropped, leaving the
default track playing with nothing in the UI saying so.

determine_audio_track_switch_strategy now decides by whether the stream in
front of the engine carries the track at all — a direct play still selects in
place, a transcode is re-negotiated at the chosen index and resumed. Where it
resumes is the player's answer rather than the UI's: the native path has no
<video> element to read, so it sends no position, and defaulting that to zero
re-opened the film at the beginning (caught on device before it shipped).

Subtitles (DR-259). The URL was missing its `Stream.` route segment, so every
sideloaded subtitle 404ed; since media3 1.5 a sideloaded text track only
becomes a track group once its file is parsed, so 42 failed fetches left
ExoPlayer with no text tracks and selection warned `available: 0`. Verified
against a live server: the built URL answers 404, the corrected one 200. The
tests that should have caught this asserted the shape of a mock helper that
restated the format string instead of the URL the app requests — so the new
test drives the repository itself, and failed red on the old URL.

src-tauri/src/repository/online.rs

@@ -2469,8 +2469,15 @@ impl MediaRepository for OnlineRepository {
         stream_index: i32,
         format: &str,
     ) -> String {
+        // `Stream.{format}` is the route, not a filename we get to choose:
+        // Jellyfin exposes the subtitle as
+        // `/Videos/{item}/{source}/Subtitles/{index}/Stream.{format}`, and
+        // stopping at the format alone matches no route and 404s. Every
+        // sideloaded subtitle failed to load on Android because of it, leaving
+        // ExoPlayer with no text tracks to select.
+        // TRACES: UR-020 | JA-008, DR-259 | UT-234
         format!(
-            "{}/Videos/{}/{}/Subtitles/{}/{}",
+            "{}/Videos/{}/{}/Subtitles/{}/Stream.{}",
             self.server_url, item_id, media_source_id, stream_index, format
         )
     }
@@ -3019,6 +3026,35 @@ mod tests {
         )
     }
 
+    /// The reported bug: on Android every subtitle track was inert — the menu
+    /// listed 42 languages and picking one changed nothing.
+    ///
+    /// The cause is here rather than in the player. ExoPlayer sideloads each
+    /// subtitle as its own media source, and since media3 1.5 a sideloaded text
+    /// track only becomes a *track group* once its file has been fetched and
+    /// parsed. Every fetch 404ed, so `Tracks` carried no text group at all and
+    /// `setSubtitleTrack(1)` warned `available: 0` and dropped the request.
+    ///
+    /// Jellyfin's route is `/Videos/{item}/{source}/Subtitles/{index}/Stream.{fmt}`
+    /// (verified against a live server: this shape answers 200, the one built
+    /// here answered 404). The `Stream.` segment is not decoration — without it
+    /// the path matches no route.
+    ///
+    /// The old mock-based URL tests could not catch this: they asserted the
+    /// shape of a *test helper* that duplicated the format string, not of the
+    /// URL the app actually requests.
+    ///
+    /// TRACES: UR-020 | JA-008, DR-259 | UT-234
+    #[test]
+    fn subtitle_url_uses_jellyfins_stream_route() {
+        let repo = create_test_repository();
+
+        assert_eq!(
+            repo.get_subtitle_url("item123", "source456", 2, "vtt"),
+            "https://test.server.com/Videos/item123/source456/Subtitles/2/Stream.vtt"
+        );
+    }
+
     /// Build a repository wired to a real ConnectivityReporter so we can assert
     /// how `report_outcome` classifies each `RepoError` into reachability.
     /// (No app handle → event emission is a harmless no-op.)