chore(release): 0.6.0

Android native video renders a picture, and its transport works.

The path shipped once as audio with no picture and was reverted with the
compositing named as the suspect. It was not the compositing: five independent
defects sat between ExoPlayer and the screen, each able to produce that symptom
on its own — the app shell painting over the surface through a CSS rule aimed at
an attribute nothing set, a poster card with no way to lift on a path that
renders no <video>, JS bridges racing the page load and losing permanently, a
SurfaceView that was never detached, and a frontend that told Rust a webview
element was playing when none existed, so every play/pause intent was aimed at
something that was not there.

Native video stays opt-in. Turning it on surfaced a further unverified path —
the background-audio return is written only for the webview element — and
rotation still needs device confirmation.

Minor rather than patch: the player's touch behaviour changes for everyone (the
control bar now auto-hides on touchscreens, and the system bars go away with the
player), not only for those who opt into native video.

CHANGELOG.md

@@ -9,6 +9,65 @@ generated trace matrix lives in [docs/traceability.md](docs/traceability.md).
 For how long each fixed defect had been shipping before it was found, see
 [docs/defect-windows.md](docs/defect-windows.md).
 
+## v0.6.0
+
+### 🐛 Fixes
+
+- **Android native video actually shows a picture.** It shipped once as *audio
+  with no picture* and was reverted with the compositing named as the suspect
+  (DR-172). The compositing was not at fault; five independent defects sat
+  between ExoPlayer and the screen, each able to produce that symptom alone. The
+  app shell painted over the video surface through a CSS rule targeting
+  `[data-app-shell]`, an attribute no component had ever set in any commit
+  (DR-185). The poster/title card had no way to lift on a path that renders no
+  `<video>` element, so a black card covered the surface for the whole session
+  (DR-182). The JavaScript bridges were installed by a 500 ms tree walk that
+  raced the page load — and lost permanently when it lost, because the
+  re-injection guard then declined to retry — so `setTransparent(true)` could
+  never arrive (DR-183). The `SurfaceView` was never detached, leaking one per
+  video and leaving picture-in-picture's gate stuck open (DR-184). Verified on a
+  device: logcat now carries `WebView transparent = true` and
+  `Marking media ready` with video on screen, the pair the original
+  investigation went looking for and could not find.
+  (UR-003, UR-004, UR-041 → DR-182, DR-183, DR-184, DR-185)
+
+- **Play and pause reach the player that is actually rendering.** Transport did
+  nothing on the native video path — from the on-screen tap, from the control
+  bar, and from a direct command invocation — while seek and skip kept working,
+  because those decide elsewhere. Rust routes play/pause to the webview `<video>`
+  whenever it believes one is active, and the player route mirrored element state
+  into that belief unconditionally, including from a ten-second progress
+  interval. So on the native path the frontend re-declared every ten seconds that
+  an element was playing when none existed, and every intent was emitted at
+  something that was not there. The mirror now lives where `useHtml5Element` is
+  known. This also explains the flashing transport controls, since they key off
+  the play state that was being contradicted on every tick.
+  (UR-005, UR-003 → DR-193, DR-195)
+
+- **The player's controls hide themselves on a touchscreen.** The auto-hide timer
+  was armed only from `mousemove`, which a touch device never fires, so the
+  control bar stayed over the video for the whole film. It is now armed on entry
+  and on every touch, and pinned open while paused, seeking, or with a menu open.
+  (UR-003, UR-066 → DR-189)
+
+- **The system bars go away with the player.** Immersive mode had exactly one
+  caller — the fullscreen button — so opening a video left the status and
+  navigation bars painted over it until the user pressed a control most never
+  press. (UR-066, UR-003 → DR-187)
+
+### 🔬 Internal
+
+- Native video presents through a `TextureView` rather than a `SurfaceView`. A
+  SurfaceView renders on its own layer outside the app window and punches a
+  transparent region through it, and Android's own graphics documentation warns
+  that overlays do not composite reliably above one. (UR-003, UR-004 → DR-192)
+
+- Native Android video remains **opt-in**, and is not yet the default. Turning it
+  on surfaced a further unverified path: returning from background audio is
+  implemented only for the webview element, so playback stays dead on the native
+  path (DR-190, proposed). Rotation still needs device confirmation (DR-194).
+  (UR-003 → DR-188)
+
 ## v0.5.5
 
 ### ✨ Features

package.json

@@ -1,6 +1,6 @@
 {
   "name": "jellytau",
-  "version": "0.5.5",
+  "version": "0.6.0",
   "description": "",
   "type": "module",
   "packageManager": "bun@1.3.5",

src-tauri/Cargo.lock

@@ -2018,7 +2018,7 @@ dependencies = [
 
 [[package]]
 name = "jellytau"
-version = "0.5.5"
+version = "0.6.0"
 dependencies = [
  "aes-gcm",
  "async-trait",

src-tauri/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "jellytau"
-version = "0.5.5"
+version = "0.6.0"
 description = "A Tauri App"
 authors = ["you"]
 edition = "2021"

src-tauri/tauri.conf.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "jellytau",
-  "version": "0.5.5",
+  "version": "0.6.0",
   "identifier": "com.dtourolle.jellytau",
   "build": {
     "beforeDevCommand": "bun run dev",