refactor(player): delete the webview video path; mpv selects its own tracks

DR-235 phase 3. Every video renderer is native now: mpv on Linux and
Windows, ExoPlayer on Android, all drawing behind the transparent
webview. The HTML5 <video> path is gone, not bypassed:

- Frontend: hls.js, Html5PlayerAdapter and its compatibility shim, the
  createAdapter factory, streamTransport, hlsRecovery, timeTracking,
  videoFit, the <video>/<track> markup and every element handler in
  VideoPlayer (3277 -> 2144 lines), the experimentalNativeVideo store
  and its Settings toggle, webviewVideoFallback/supportsNativeVideo, and
  the setHtml5VideoState PiP bridge call. NativePlayerAdapter is the one
  video adapter; webview audio gets its own adapter kind.
- Rust: use_html5 dropped from player_seek_video,
  player_switch_audio_track and player_set_stream_quality with the
  Html5* strategies and ReloadStream responses; use_html5_element and
  VideoBackend dropped from PlayerStatus; player_play_item always loads
  the backend (set_current_item removed); Capabilities::webview removed;
  the WebKitGTK GStreamer/VAAPI setup (and its gst-inspect spawn) removed.
- Android: the HTML5 video state in PictureInPictureManager and
  ScreenWakeManager, and the bridge method feeding it.
- CSP: connect-src loses http:/https: and worker-src loses blob: -
  both existed for hls.js; with it gone they were only an exfiltration
  channel and a blob worker for injected script. A test now keeps them
  out.

mpv takes over what the <video> element did (mpv_tracks, UT-275):
subtitles are the WebVTT list the play request carries, queued on
sub-files and selected by position in that list, starting off; audio
tracks are selected by position in the file; sid/aid are reset before
each load. Without this, Linux video had no subtitle selection and a
direct-play audio switch failed since mpv became its renderer.

Verified: Rust 948 passing, and the same 948 cross-compiled for Windows
under wine against the shipped DLL (track tests included); frontend
1111 passing; aarch64 debug APK builds. Lint warnings 158 -> 146, CI
ratchet tightened to match. Not yet seen on Windows hardware.

src/lib/components/player/subtitleTracks.ts

@@ -125,72 +125,13 @@ export async function resolveSubtitleTracks(
   return resolved.filter((t): t is RenderableSubtitleTrack => t !== null);
 }
 
-/**
- * The selection to keep once the rendered track list changes.
- *
- * Subtitles are OFF unless the user turns them on: `null` in, `null` out. The
- * server's `isDefault` flag is deliberately NOT promoted to a selection (and the
- * markup deliberately omits the `default` attribute, which would auto-show the
- * track) — the menu opens on "Off", so auto-enabling would make the UI lie about
- * what is on screen, and it would change behaviour for every user who has never
- * asked for subtitles.
- *
- * A selection that is no longer renderable (new item, or a URL that failed to
- * resolve) collapses to off, so the menu's checkmark can never point at a track
- * that does not exist on the element.
- */
-export function reconcileSelectedSubtitle(
-  tracks: readonly RenderableSubtitleTrack[],
-  selected: number | null,
-): number | null {
-  if (selected === null) return null;
-  return tracks.some((t) => t.streamIndex === selected) ? selected : null;
-}
-
-function originOf(url: string): string | null {
-  try {
-    const parsed = new URL(url);
-    if (parsed.protocol !== "http:" && parsed.protocol !== "https:") return null;
-    return parsed.origin;
-  } catch {
-    return null;
-  }
-}
-
-/**
- * The `crossorigin` value for the `<video>` element, or undefined for none.
- *
- * Text-track fetches are CORS-enabled per the HTML spec and use the *media
- * element's* CORS setting, so a cross-origin `<track>` never loads unless the
- * element opts in. The webview page's origin is `tauri://localhost`, so every
- * subtitle served by Jellyfin is cross-origin.
- *
- * Opting in is only safe when the media itself comes from an http(s) server —
- * the same Jellyfin that already answers hls.js' cross-origin XHRs, so we know
- * it sends the headers. For a local/offline source (`file:`/`asset:`) we leave
- * the attribute off: subtitles staying dark there is the status quo, whereas
- * forcing CORS onto the video fetch could break playback outright.
- *
- * Deliberately keyed on the *count of subtitle streams* rather than on the
- * resolved tracks: both inputs are known at first render, so the attribute is
- * decided before the element starts loading and never flips underneath an
- * in-flight media fetch.
- */
-export function videoCrossOriginMode(
-  streamUrl: string,
-  subtitleStreamCount: number,
-): "anonymous" | undefined {
-  if (subtitleStreamCount <= 0) return undefined;
-  return originOf(streamUrl) ? "anonymous" : undefined;
-}
-
-// ===== Native (Android / ExoPlayer) path ====================================
+// ===== The native player =====================================================
 //
-// The HTML5 element gets `<track>` children; the native backend instead gets the
-// list *up front*, as part of the play request, because ExoPlayer sideloads
-// subtitles as `MediaItem.SubtitleConfiguration`s that must exist before
-// `prepare()`. There is no "add a subtitle later" — a track absent from the
-// MediaItem simply does not exist as far as the player is concerned.
+// The native backend gets the list *up front*, as part of the play request:
+// ExoPlayer sideloads subtitles as `MediaItem.SubtitleConfiguration`s that must
+// exist before `prepare()`, and mpv queues them as external files for the load.
+// There is no "add a subtitle later" — a track absent from the request simply
+// does not exist as far as the player is concerned.
 
 /**
  * Map resolved tracks onto the wire shape `PlayItemRequest.subtitles` carries.