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/device_profile.rs

@@ -195,17 +195,15 @@ pub fn subtitle_supports_external_delivery(codec: Option<&str>) -> bool {
 /// the raw list makes Jellyfin direct-play a track the webview cannot decode, and
 /// the user gets picture with no sound.
 ///
-/// Which renderer gets it is not fixed: Linux is always the element, and Android
-/// follows `experimentalNativeVideo`, which took ExoPlayer as its default in
-/// DR-161 but is a user setting either way. So the *narrow* list is the only one
-/// that holds on both sides of that switch. The cost is a Dolby-licensed Android
-/// device transcoding an E-AC-3 track its ExoPlayer could have direct-played;
-/// the alternative is silence for everyone the switch lands the other way, which
-/// is the bug this exists to prevent.
-///
-/// The gap is widest on devices whose vendor licenses Dolby: a phone with
-/// `c2.dolby.eac3.decoder` reports `eac3`, so it — and only it — gets a silent
-/// direct play where a leaner device is transcoded to AAC and plays fine.
+/// Which renderer gets it depends on the platform. Linux draws video in the
+/// element (unless mpv native video is switched on), so it gets the narrow list.
+/// Android draws video only in ExoPlayer: it used to follow the
+/// `experimentalNativeVideo` setting, which could send video to the webview, and
+/// while that switch existed the narrow list was the only one true on both sides
+/// of it. DR-293 removed the webview video path on Android, so there the
+/// platform list is the whole answer — it includes the FFmpeg extension's
+/// AC-3/E-AC-3/DTS/TrueHD, which `CodecDetector` reports alongside the
+/// `MediaCodecList` decoders.
 ///
 /// This applies to the *video* direct-play profile only. Audio-only playback
 /// really is ExoPlayer's, so its profile keeps the full platform list.
@@ -323,6 +321,9 @@ pub fn renderer_can_decode_audio(codec: &str) -> bool {
 /// Whether the webview `<video>` element can decode this audio codec.
 ///
 /// TRACES: UR-004 | DR-149 | UT-148
+// Unreachable on Android since DR-293: video renders only in ExoPlayer there,
+// so every caller goes through `renderer_can_decode_audio`'s device-list arm.
+#[cfg_attr(target_os = "android", allow(dead_code))]
 pub fn webview_can_decode_audio(codec: &str) -> bool {
     WEBVIEW_AUDIO_CODECS
         .iter()