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.

docs/specs/desktop-native-video.md

@@ -7,7 +7,9 @@ webview fallback is offered). **Left:** Linux's device profile still claims only
 the direct-play gain is not yet taken; `hwdec` is unset, so mpv decodes in
 software (DR-236); a failed surface attach only logs, it does not surface an
 error; the phase 1 soak and X11/Wayland criteria are unrecorded; phases 2 and 3.
-Phase 3 also deletes the now-inert frontend switch (`experimentalNativeVideo`,
+Phase 2 has started from its build half: Windows now links and ships libmpv
+(for audio, see windows-native-audio-backend.md); its video surface is not
+written. Phase 3 also deletes the now-inert frontend switch (`experimentalNativeVideo`,
 `nativeVideoWanted`, the Settings toggle and the adapter's suppressor flag),
 which no platform reaches since `webview_video_fallback` became false everywhere.
 **Requirements:** UR-080 (new) → DR-231 … DR-237 (new); IR-033 (new)

docs/specs/windows-native-audio-backend.md

@@ -1,8 +1,15 @@
 # Spec: Windows native audio backend
 
-**Status:** Proposed — not started. Windows still runs on
-`WebviewAudioBackend`. Blocked on [libmpv2-migration.md](libmpv2-migration.md),
-whose crate swap has not landed either.
+**Status:** Partially implemented — code and packaging done, **unverified on
+Windows hardware**. `MpvBackend` is the Windows audio backend (`ao=wasapi`);
+the builder image carries zhongfly's pinned LGPL `libmpv-2.dll` plus a generated
+MSVC `mpv.lib`, and the NSIS installer ships the DLL beside `jellytau.exe` with
+its licence texts ([build-windows.md](../build/build-windows.md)). Done *before*
+the libmpv2 migration after all: the current `libmpv` pin cross-links fine, and
+the migration now has one call site to keep safe (`mpv_command`, DR-298) rather
+than a crate API to port twice. **Left:** every acceptance criterion that needs a
+Windows machine — audible volume/EQ/normalization/gapless, seek/queue/sleep
+timer, and the clean-VM install test.
 **Requirements:** UR-003, UR-027, UR-032, UR-033 → DR-030, DR-035, DR-036;
 ⚠️ the suggested id **IR-030 has since been allocated** to the scheduled catalog
 crawl — allocate a fresh id (IR-033 or later) on implementation