fix(player): make Android native video actually visible, and usable

DR-172 reverted native video to opt-in after it shipped as audio with no
picture, naming the compositing as the suspect. The compositing was fine. Five
separate defects sat between ExoPlayer and the screen, each able to produce that
exact symptom on its own, and each invisible to the others.

DR-185 — the app shell painted over the surface. app.css clears the page's
opaque layers through three selectors, one of which targets `[data-app-shell]`,
an attribute NO component has ever set, in any commit. The shell paints
--color-background across the whole viewport and VideoPlayer stacks above it, so
the WebView composited opaque no matter what else was cleared. Invisible three
ways over: the CSS is valid, the selector is plausible, and a rule matching
nothing looks exactly like a rule matching something already transparent.

DR-182 — nothing could lift the poster card. Every markMediaReady() call site is
an HTML5 <video> event, and the native branch renders no element, so the black
title card covered the surface for the entire session. The first fix hooked
`player://position-update` / `player://state-changed`; those channels are never
emitted by the backend, so it passed a test that fired them by hand and did
nothing on a device. Driven from the player store now, as the seek bar already
was.

DR-183 — the JS bridges raced the page load. Installed 500ms after onCreate by
walking the view tree, while WebView binds injected objects at page-load time,
and the identity guard then declined to re-inject forever. setTransparent(true)
could never arrive. Installed from WryActivity.onWebViewCreate instead, which
wry calls immediately before the first loadUrl.

DR-184 — the SurfaceView was never detached. detachVideoSurface had no callers
anywhere, mirroring the DR-151 defect: every native video left its surface
parented to the content view and the next one stacked another beneath it.

DR-191 — the overlay stopped repainting. Incremental damage (the clock's text,
the control bar's opacity) never reached the screen while structural changes did,
so the progress bar froze, the controls would not fade, and the play overlay
appeared to work because it is added and removed from the DOM. Driven from the
Activity via postInvalidateOnAnimation while compositing is on.

Two UI defects only this path could reveal came with them: isPlaying froze at
its initial value, leaving the play overlay dimming and covering the video
(DR-186), and the control bar's auto-hide was armed solely by mousemove, which a
touchscreen never fires (DR-189). Immersive mode now applies on entering the
player rather than only via the fullscreen button (DR-187).

Verified on a device (Honor ROD2-W09, Android 16): logcat carries
`WebView transparent = true` and `Marking media ready` with video on screen —
the pair DR-172 went looking for and could not find — and skip, seek, rotation
and subtitle rendering were exercised by hand.

The default stays OFF (DR-188). Turning it on surfaced a further unverified
sub-path: returning from background audio is HTML5-only, so playback stays dead
(DR-190, proposed). Shipping it would have repeated DR-161 exactly — a verified
sub-path made default over an unverified one.

src/lib/utils/nativeVideoLayers.test.ts

@@ -0,0 +1,91 @@
+/**
+ * Every opaque layer the native-video CSS claims to clear must actually exist.
+ *
+ * TRACES: UR-003, UR-004 | DR-185 | UT-186
+ *
+ * The compositing rules in app.css clear the page's painted backgrounds so the
+ * ExoPlayer SurfaceView behind the WebView can be seen. One of the three
+ * selectors, `[data-app-shell]`, was written against an attribute that **no
+ * component ever set** — in any commit — so the app shell went on painting
+ * `--color-background` across the whole viewport, underneath a player that had
+ * correctly made itself transparent. The WebView therefore composited opaque
+ * and the surface could never show through.
+ *
+ * That failure is invisible three ways over: the CSS is valid, the selector is
+ * plausible, and the symptom (black screen, audio fine) is identical to a
+ * genuine compositing failure — which is how it survived DR-150 through DR-172.
+ * A rule that matches nothing is the specific defect worth a tripwire, so this
+ * asserts the relationship rather than the rule: every attribute the block
+ * targets is set somewhere in the app.
+ */
+
+import { describe, it, expect } from "vitest";
+import fs from "node:fs";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const here = path.dirname(fileURLToPath(import.meta.url));
+const srcRoot = path.resolve(here, "../..");
+
+function read(file: string): string {
+  return fs.readFileSync(file, "utf-8");
+}
+
+/** Every .svelte file under src/. */
+function svelteFiles(dir: string, found: string[] = []): string[] {
+  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
+    const full = path.join(dir, entry.name);
+    if (entry.isDirectory()) svelteFiles(full, found);
+    else if (entry.name.endsWith(".svelte")) found.push(full);
+  }
+  return found;
+}
+
+/**
+ * The selector list of the `[data-native-video="active"]` rule in app.css.
+ * Returned verbatim, one selector per entry.
+ */
+function compositingSelectors(css: string): string[] {
+  const marker = 'html[data-native-video="active"]';
+  const start = css.indexOf(marker);
+  expect(start, "app.css no longer contains the native-video rule").toBeGreaterThan(-1);
+  const open = css.indexOf("{", start);
+  return css
+    .slice(start, open)
+    .split(",")
+    .map((s) => s.trim())
+    .filter(Boolean);
+}
+
+describe("native-video compositing layers (DR-185)", () => {
+  const css = read(path.join(srcRoot, "app.css"));
+  const selectors = compositingSelectors(css);
+  const markup = svelteFiles(srcRoot).map(read).join("\n");
+
+  it("clears the app shell, which paints over the whole viewport", () => {
+    // The shell is the layer directly between the player and the WebView; if it
+    // stays painted, nothing below it can be seen however transparent the
+    // player and the WebView widget are.
+    expect(selectors.some((s) => s.includes("[data-app-shell]"))).toBe(true);
+    expect(markup).toContain("data-app-shell");
+  });
+
+  it("targets no attribute that nothing in the app sets", () => {
+    const attributes = selectors
+      .flatMap((selector) => [...selector.matchAll(/\[([a-zA-Z-]+)(?:[=\]])/g)])
+      .map((match) => match[1])
+      // data-native-video is set imperatively on <html> by nativeVideo.ts, not
+      // in markup, so it is verified against that module instead.
+      .filter((attr) => attr !== "data-native-video");
+
+    const unset = [...new Set(attributes)].filter((attr) => !markup.includes(attr));
+    expect(unset, `app.css targets attributes no component sets: ${unset.join(", ")}`)
+      .toEqual([]);
+  });
+
+  it("still sets data-native-video on <html> from the store", () => {
+    const store = read(path.join(srcRoot, "lib/stores/nativeVideo.ts"));
+    expect(store).toContain("data-native-video");
+    expect(store).toContain("documentElement");
+  });
+});

src/lib/utils/videoSurface.ts

@@ -1,7 +1,7 @@
 /**
  * Native video surface compositing, Android only.
  *
- * TRACES: UR-003, UR-004 | DR-150, DR-151
+ * TRACES: UR-003, UR-004 | DR-150, DR-151, DR-183
  *
  * On Android, ExoPlayer renders video into a SurfaceView that sits *behind* the
  * Tauri WebView (`setZOrderMediaOverlay(false)`, added at index 0 of the content
@@ -65,8 +65,23 @@ export function enableNativeVideoCompositing(): void {
   // Page layer first: if the Kotlin call succeeded but this threw, the user
   // would see through the app to the home screen.
   nativeVideoActive.set(true);
+  const androidVideoSurface = bridge();
+  if (!androidVideoSurface) {
+    // Say so loudly. Every bridge call in this file is optional-chained, so a
+    // missing bridge is silent — and a silently-skipped setTransparent(true) is
+    // indistinguishable on screen from a compositing failure: ExoPlayer renders
+    // correctly behind a WebView that never stopped painting its own opaque
+    // background. That ambiguity is what DR-172 was left holding. MainActivity's
+    // console bridge forwards this to logcat under the JellyTauWeb tag.
+    console.error(
+      "[videoSurface] AndroidVideoSurface bridge is MISSING - the webview will " +
+        "stay opaque and native video will play as audio with no picture"
+    );
+    return;
+  }
   try {
-    bridge()?.setTransparent(true);
+    androidVideoSurface.setTransparent(true);
+    console.log("[videoSurface] compositing enabled (setTransparent(true) sent)");
   } catch (err) {
     console.warn("[videoSurface] setTransparent(true) failed:", err);
     nativeVideoActive.set(false);