fix(player): make transport reach the player that is actually rendering

Play/pause did nothing on the Android native video path — from the on-screen
tap, from the control bar, and from a direct player_toggle invocation — while
seek and skip kept working. That asymmetry was the whole clue: seek decides in
player_seek_video, transport decides in toggle_playback.

DR-195 is the cause. `html5_playing` is Rust's record of "a webview <video> is
active and in this state", and toggle_playback/play/pause all route transport to
that element whenever it is set. The player route mirrored element state into it
UNCONDITIONALLY — from handleReportStart and, fatally, from handleReportProgress,
which VideoPlayer calls on a 10-second interval. So on the native path the
frontend re-declared every ten seconds that an element was playing when none
existed, and every transport intent was emitted into the void. It also explains
the flashing: the control bar and the JRay overlay both key off isPlaying, which
was being contradicted on every tick. The mirror now lives in
mirrorElementStateToRust() in VideoPlayer, gated on useHtml5Element — the only
place that knows whether an element renders at all. The route cannot tell the
paths apart, which is exactly how it came to lie.

DR-193 hands transport authority back to the native backend when an item loads
into it. Necessary but insufficient alone: the progress interval put the flag
straight back, which is why the first device test after it still failed.

DR-192 presents native video through a TextureView instead of a SurfaceView. A
SurfaceView renders on its own layer outside the app window and punches a
transparent region through it, and everything drawn above that hole — here, the
entire Svelte UI — depends on that composition path. The overlay dropped its
incremental damage: the DOM advanced (slider 476 -> 479 across three seconds)
behind a screen showing neither, so the progress bar froze, controls would not
fade and rotation lost the transport UI, while structural DOM changes got
through, which is why the play overlay always appeared to work. It supersedes
DR-191, which forced redraws in a loop and treated the symptom.

DR-194 hides the video view across a resize and reveals it two frames later. A
TextureView retains its last frame, so between a rotation and the re-fit landing
that frame is stretched across the old rect and the previous frame flashes in
what should be the letterbox bars.

Verified on device (Honor ROD2-W09, Android 16) by driving ADB and reading the
live DOM over the devtools socket: surface tap pauses (position frozen across 12
seconds, overlay raised, transport flipped) and resumes; the control bar does
both. UT-189 drives the real 10-second interval under fake timers — an earlier
version asserted on a freshly mounted player, passed with the guard deleted, and
guarded nothing.

Still open, and deliberately not claimed: DR-192's effect on the overlay repaint
is unverified on device, DR-194's letterbox reset is untested, and the native
default (DR-188) stays off pending DR-190, the background-audio return.

src/lib/components/player/VideoPlayer.svelte

@@ -1016,6 +1016,7 @@
       progressInterval = setInterval(() => {
         if (isPlaying && !isSeeking && onReportProgress) {
           onReportProgress(currentTime, false, reportMediaId);
+          mirrorElementStateToRust(false);
         }
       }, 10000);
     }
@@ -1449,6 +1450,33 @@
     }
   });
 
+  /**
+   * Mirror the **webview element's** play/pause and position into Rust.
+   *
+   * Only ever when the element is what renders. `html5_playing` is Rust's record
+   * of "a webview element is active and in this state", and `toggle_playback`,
+   * `play` and `pause` all route transport to that element when it is set. So
+   * reporting it from the native path is not a harmless extra: it hands
+   * transport authority to an element that does not exist, and every play/pause
+   * intent is then emitted into the void. That is exactly what made the pause
+   * button dead on the native path — from the on-screen tap, the control bar,
+   * and even a direct `player_toggle` invocation — while seek and skip kept
+   * working, because they decide elsewhere.
+   *
+   * This lived in the player route's reporting callbacks, which cannot tell the
+   * two rendering paths apart and so mirrored unconditionally — including from
+   * the 10-second progress interval, which is why the flag came back after
+   * DR-193 cleared it at load. It belongs here, where `useHtml5Element` is
+   * known.
+   *
+   * TRACES: UR-005, UR-003 | DR-195 | UT-189
+   */
+  function mirrorElementStateToRust(paused: boolean) {
+    if (!useHtml5Element) return;
+    html5Adapter.reportState(paused ? "paused" : "playing", reportMediaId ?? null);
+    html5Adapter.reportPosition(currentTime, duration, { force: true });
+  }
+
   function handlePlay() {
     isPlaying = true;
     startTimeUpdates(); // Start RAF loop for smooth time updates