fix(player): ExoPlayer can seek a transcode in place; mpv cannot

A regression I introduced in DR-246 and did not catch, because the capability
was declared once for "native engines" as though being native were the
property that mattered.

It is not. Speaking HLS is. ExoPlayer is a full HLS client: like hls.js it
seeks within the VOD playlist it was handed and lets the server catch up. mpv's
HLS demuxer will not make the server produce segments from a new offset, so it
has to re-open the stream. Grouping them together declared false for both, so
on Android a transcoded seek began re-opening the stream where it previously
seeked in place — the same class of defect DR-238 was about, reintroduced on
the platform I had not exercised.

Capabilities::native() is gone, replaced by mpv() and exoplayer(), and the
composition root chooses per platform through engine_capabilities(). Treating a
category as a proxy for an ability is precisely the inference this design
removes; a helper named after the category invited it straight back in.

Not yet verified on a device. The conformance cases run against JellyTauPlayer
in isolation and do not cover a transcoded seek, PiP, background audio or the
media session — none of which have been exercised since the controller port.

src-tauri/src/player/mod.rs

@@ -2253,7 +2253,7 @@ impl Default for PlayerController {
         Self::new(
             Box::new(LegacyPlayer::new(
                 NullBackend::new(),
-                crate::player::media_player::Capabilities::native(),
+                crate::player::media_player::Capabilities::mpv(),
             )),
             playback_reporter,
             position_throttler,