feat(windows): mpv plays audio on Windows, with libmpv shipped in the installer

libmpv on Windows (DR-237):
- The builder image carries zhongfly's LGPL libmpv-2.dll, pinned by
  asset name and sha256, plus an MSVC mpv.lib generated from the DLL's
  own mpv_* exports (the archive ships only a MinGW .dll.a). LGPL, not
  the GPL builds: no x264/x265, mpv -Dgpl=false; FFmpeg is version3, so
  LGPL-3.0. THIRD_PARTY_NOTICES.md records it.
- build-windows-cross.sh stages both files into src-tauri/windows-libs/;
  build.rs links mpv.lib from there and tauri.windows.conf.json bundles
  the DLL beside jellytau.exe from there, with the licence texts under
  licenses/. One directory, so the DLL shipped is the one linked.
- Workflows move to builder image 2026.09.1.

Windows audio:
- MpvBackend replaces WebviewAudioBackend on Windows (ao=wasapi), so
  volume, EQ, normalization and gapless work there as on Linux. Local
  files are passed to mpv as native paths, not file:// URLs.

Fixes found on the way:
- player_play_item decided "does the backend render video" with
  cfg!(not(linux)), true on Windows, while get_player_status sent
  Windows video to the <video> element. With mpv as the backend that
  would decode every film's soundtrack twice. All three callers now
  ask video_renders_natively() (UT-273).
- confine_queued_path rebuilt paths with PathBuf::push, so on Windows
  a queued `downloads/x` was stored as `downloads\x`, no longer the
  spelling the app built. It now keeps the caller's separator (UT-205,
  which only ever ran on Linux, failed under Windows).

Verified: jellytau.exe imports libmpv-2.dll; the full unit suite
cross-compiled for Windows passes under wine against the shipped DLL
(943/943, including the mpv injection and TLS tests); the NSIS
installer contains the DLL and licence texts. Not yet run on real
Windows hardware.

src-tauri/build.rs

@@ -1,3 +1,32 @@
+use std::path::PathBuf;
+
 fn main() {
+    link_windows_libmpv();
     tauri_build::build()
 }
+
+/// Point the MSVC linker at `mpv.lib` for a Windows target.
+///
+/// `libmpv-sys` emits `rustc-link-lib=mpv` and nothing else; on Linux the
+/// system library satisfies it. For Windows the import library and the DLL it
+/// names are staged into `src-tauri/windows-libs/` by
+/// `scripts/build-windows-cross.sh` from the builder image's pinned libmpv
+/// build — the same directory `tauri.windows.conf.json` bundles the DLL from,
+/// so what is linked against and what is shipped cannot come from two places.
+///
+/// TRACES: UR-004 | DR-237
+fn link_windows_libmpv() {
+    if std::env::var("CARGO_CFG_TARGET_OS").as_deref() != Ok("windows") {
+        return;
+    }
+    let dir = PathBuf::from(std::env::var("CARGO_MANIFEST_DIR").unwrap()).join("windows-libs");
+    println!("cargo:rerun-if-changed={}", dir.join("mpv.lib").display());
+    if !dir.join("mpv.lib").is_file() {
+        panic!(
+            "{} is missing. Windows builds link libmpv from the builder image; \
+             build through scripts/build-windows-cross.sh, which stages it.",
+            dir.join("mpv.lib").display()
+        );
+    }
+    println!("cargo:rustc-link-search=native={}", dir.display());
+}