fix(player): let the background-audio toggle govern backgrounding again

Locking the screen kept a video's audio playing whether or not the
background-audio button was on. Reported as "audio only mode is always
active even if not selected".

The button (UR-040) was built for the WebView <video> path, where losing
visibility kills the decode: it chose between handing off to a native
audio stream and letting playback stop. Native video then became the
default renderer (DR-188), and on that path playback runs through
ExoPlayer inside a MediaSessionService -- a foreground media service
whose entire purpose is to keep playing while the app is hidden. Nothing
stopped it, and nothing in the codebase paused on background.

So the button governed a handoff that no longer had a gap to bridge.
There was no interruption to paper over, and a user who never touched it
got background playback anyway.

The gating made it self-concealing: MainActivity.onStop only dispatched
'jellytau-background' when backgroundAudioEnabled was already true. The
one notification that the app had gone away was itself conditional on the
setting, so with the button OFF nothing could react even in principle.
onStop and onStart now fire unconditionally and carry the two facts only
the activity knows -- whether the toggle is armed, and whether Android
put the window into picture-in-picture.

What to do about it is decided in Rust (player/background_policy.rs),
because it depends on whether the item has a picture to lose:

  video + toggle off  -> Pause
  video + toggle on   -> HandOffToAudio
  music, either       -> KeepPlaying   (no picture to give up)
  picture-in-picture  -> KeepPlaying   (the window is still on screen)

It takes no renderer parameter on purpose. Two renderers with two
behaviours and one toggle reaching only one of them is what produced the
defect; a rule that cannot see the renderer cannot reproduce it.

Two failure modes are deliberate. A decision call that fails leaves
playback alone rather than risking silence mid-listen. An event with no
detail -- older Kotlin against newer JS -- reads as "armed, not PiP",
degrading to the previous behaviour instead of pausing unexpectedly.

Foregrounding resumes only what backgrounding paused: a video the user
paused themselves before locking stays paused.

Written test-first per CLAUDE.md. The stub encoded today's behaviour
(nothing ever pauses) and failed exactly as reported --
`left: KeepPlaying, right: Pause` -- before the rule was implemented.

Verified on a device, R8-minified, both directions:

  [player_background_action] video=true armed=false pip=false -> Pause
  [player_background_action] video=true armed=true  pip=false -> HandOffToAudio

UR-040 / DR-224 / UT-211.

src-tauri/android/src/main/java/com/dtourolle/jellytau/MainActivity.kt

@@ -164,17 +164,33 @@ class MainActivity : TauriActivity() {
    */
   override fun onStop() {
     super.onStop()
-    if (backgroundAudioEnabled) {
-      dispatchWebEvent("jellytau-background")
+    // Fires unconditionally now. It used to be gated on backgroundAudioEnabled,
+    // which meant the frontend was never told the app had gone away unless the
+    // toggle was already on -- so with the toggle OFF nothing could react, and
+    // on the native path ExoPlayer's media service simply kept playing. That is
+    // the whole defect: the toggle appeared to do nothing because the only
+    // notification of backgrounding was itself gated on the toggle (DR-224).
+    //
+    // What to DO about it is decided in Rust (player_background_action); this
+    // only reports the two facts the activity alone knows.
+    val inPip = if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.N) {
+      isInPictureInPictureMode
+    } else {
+      false
     }
+    dispatchWebEvent(
+      "jellytau-background",
+      "{\"backgroundAudioArmed\": $backgroundAudioEnabled, \"inPictureInPicture\": $inPip}"
+    )
   }
 
   /** The app is visible again — tell the frontend to resume WebView video. */
   override fun onStart() {
     super.onStart()
-    if (backgroundAudioEnabled) {
-      dispatchWebEvent("jellytau-foreground")
-    }
+    // Also unconditional, for the same reason: a video paused on background has
+    // to be told it is visible again, and that pause happens with the toggle
+    // OFF. The frontend ignores this when it has nothing to restore.
+    dispatchWebEvent("jellytau-foreground")
   }
 
   /**
@@ -182,14 +198,14 @@ class MainActivity : TauriActivity() {
    * evaluateJavascript pattern already used to unmute video elements. Posted to
    * the WebView thread; safe no-op if the WebView isn't found yet.
    */
-  private fun dispatchWebEvent(name: String) {
+  private fun dispatchWebEvent(name: String, detailJson: String = "null") {
     val webView = mediaWebView ?: run {
       android.util.Log.w("MainActivity", "dispatchWebEvent('$name'): no WebView")
       return
     }
     webView.post {
       webView.evaluateJavascript(
-        "window.dispatchEvent(new CustomEvent('$name'));",
+        "window.dispatchEvent(new CustomEvent('$name', { detail: $detailJson }));",
         null
       )
       android.util.Log.d("MainActivity", "Dispatched web event: $name")