feat(android): play the original file — decode Dolby/DTS audio with FFmpeg

Android ships no AC-3, E-AC-3, DTS or TrueHD decoders; they are licensed
codecs, present only where a vendor paid for them. The ROD2-W09 tablet has a
vendor DTS decoder and no AC-3/E-AC-3 at all. So every film with Dolby audio
was re-encoded by the server, for streaming and for download alike, and a
transcoded download has no Content-Length and ignores Range: ~1 MB/s,
restarting from byte zero on every network blip.

ExoPlayer now carries Jellyfin's media3 FFmpeg audio decoder in extension
mode ON (platform decoders first, FFmpeg for what they lack), and
CodecDetector reports its codecs so the device profile and the download
policy agree with what actually decodes. The download policy judges audio
against the renderer that will play the file (renderer_can_decode_audio)
instead of the webview's list, so Android downloads are always the direct
copy — a 910 MB E-AC-3 5.1 episode downloaded in 94 s and played offline.

The webview video path is removed on Android: it decodes none of these
codecs, so a stored "native video off" would play every original-file
download silent. Rust reports webview_video_fallback (false on Android, true
only beside mpv native video on Linux); Settings offers the switch and the
player honours it only then. Linux keeps the fallback and, with it, the
server transcode for undecodable audio.

The decoder is GPL-3.0; the distributed APK carries its terms and the source
stays MIT (THIRD_PARTY_NOTICES.md). The on-device remux spec this replaces is
folded into 05-platform-backends.md and deleted.

DR-293, UT-259, UT-262.

src-tauri/src/repository/online.rs

@@ -2530,28 +2530,32 @@ impl MediaRepository for OnlineRepository {
                 params.push("allowVideoStreamCopy=false".to_string());
             }
             // "original" (and any unknown value) → direct, resumable copy —
-            // unless the audio in that copy is undecodable where the file will
-            // be played back. A download is watched with no server in reach, so
-            // it has to satisfy the same constraint DR-149 applies to streams:
-            // the webview `<video>` element renders video on both platforms and
-            // decodes none of AC-3/E-AC-3/DTS/TrueHD. Copying those bytes to
-            // disk is what made a downloaded film play offline as picture with
-            // no sound while the same film had sound when streamed.
+            // unless the audio in that copy is undecodable by the renderer that
+            // will play the file. A download is watched with no server in reach,
+            // so there is nothing to fall back to: copying a track the renderer
+            // cannot decode is what made a downloaded film play offline as
+            // picture with no sound while the same film had sound when streamed
+            // (DR-171).
             //
-            // Only the *audio* is re-encoded. `allowVideoStreamCopy` keeps an
-            // h264 source's picture byte-for-byte, so "original" still means
-            // original quality, and no bitrate or resolution cap is added. A
-            // source the webview could not have rendered anyway (HEVC) is
-            // re-encoded to h264 as a side effect, which is the only form of it
-            // that would have played.
+            // "The renderer" is DR-234's per-platform answer, not the webview's
+            // list. On Android that is ExoPlayer — the only video renderer there
+            // since DR-293 removed the webview path — which decodes the device's
+            // own codecs plus AC-3/E-AC-3/DTS/TrueHD through the FFmpeg
+            // extension. So on Android every `original` download is a
+            // `Static=true` copy: fast, resumable (HTTP 206), and the real file.
+            // Judging against the webview's list instead turned most films into a
+            // server transcode — generated as it is sent, no `Content-Length`,
+            // `Range` ignored — measured at ~1 MB/s against 14.5 MB/s for the
+            // copy, and restarting from zero on every network blip.
             //
-            // The cost of the transcode is that the response is no longer
-            // range-resumable, which is exactly why this is decided per item
-            // rather than applied to every `original` download.
+            // On Linux the webview still draws video, so the renderer's list *is*
+            // the webview's and the transcode below still applies there. Only the
+            // *audio* is re-encoded: `allowVideoStreamCopy` keeps an h264 source's
+            // picture byte-for-byte, so "original" still means original quality.
             //
-            // TRACES: UR-071, UR-004 | DR-171 | UT-166
+            // TRACES: UR-071, UR-004 | DR-171, DR-293 | UT-166
             None => match source_audio_codec {
-                Some(codec) if !super::device_profile::webview_can_decode_audio(codec) => {
+                Some(codec) if !super::device_profile::renderer_can_decode_audio(codec) => {
                     params.push("videoCodec=h264".to_string());
                     params.push("allowVideoStreamCopy=true".to_string());
                     params.push("audioCodec=aac".to_string());
@@ -3731,13 +3735,17 @@ mod tests {
     /// holds audio this device cannot decode.
     ///
     /// `Static=true` hands back the source bytes untouched, E-AC-3/AC-3/DTS
-    /// track included, and video plays through the webview `<video>` element on
-    /// both platforms — which decodes none of them. Streaming already knows this
-    /// (DR-149 forces a transcode over the server's own direct-play offer); the
-    /// download path did not, so a downloaded film played offline as picture with
-    /// no sound while the very same film had sound when streamed.
+    /// track included. Where the webview `<video>` element renders video —
+    /// Linux, which is where this test runs — none of them decode. Streaming
+    /// already knew this (DR-149); the download path did not, so a downloaded
+    /// film played offline as picture with no sound.
     ///
-    /// TRACES: UR-071, UR-004 | DR-171 | UT-166
+    /// On Android the renderer is ExoPlayer with the FFmpeg extension, which
+    /// decodes all of these, so the same call there yields a `Static=true` copy
+    /// (DR-293). The policy is `renderer_can_decode_audio`; this test pins its
+    /// webview half.
+    ///
+    /// TRACES: UR-071, UR-004 | DR-171, DR-293 | UT-166
     #[test]
     fn test_video_download_url_original_transcodes_undecodable_audio() {
         let repo = create_test_repository();