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/src/player/background_policy.rs

@@ -0,0 +1,155 @@
+//! What playback should do when the app stops being visible.
+//!
+//! TRACES: UR-040 | DR-224 | UT-211
+//!
+//! # The defect this exists for
+//!
+//! The per-player background-audio toggle (UR-040) was built for the WebView
+//! `<video>` path, where backgrounding the app kills the decode: the toggle
+//! decided whether to *hand off* to a native audio stream or let playback die.
+//!
+//! Native video then became the default renderer (DR-188). On that path playback
+//! runs through ExoPlayer inside a `MediaSessionService` — a foreground media
+//! service whose entire purpose is to keep playing when the app is not visible.
+//! Nothing stops it, and nothing in the codebase paused playback on background.
+//!
+//! So locking the screen kept the audio playing **whether or not the toggle was
+//! on**. The toggle governed a handoff that no longer had anything to hand off
+//! *from*: there was no gap in playback to bridge. A user who had never touched
+//! it got background audio anyway, which is the bug as reported.
+//!
+//! # Why the decision lives in Rust
+//!
+//! It depends on what the item *is* (a video keeps its picture; music has none
+//! to lose) and on a user setting — domain questions, not presentation ones, and
+//! the answer must be identical for both renderers. The frontend and the Android
+//! activity carry it out; neither decides it. Putting the rule in either would
+//! have reproduced exactly the split that caused this: two renderers, two
+//! behaviours, one toggle that only reached one of them.
+
+use crate::player::media::MediaType;
+
+/// What the player should do when the app is backgrounded.
+#[derive(Debug, Clone, Copy, PartialEq, Eq, serde::Serialize, serde::Deserialize, specta::Type)]
+#[serde(rename_all = "camelCase")]
+pub enum BackgroundAction {
+    /// Carry on. Music, and video the user explicitly asked to keep hearing
+    /// while it is in a picture-in-picture window.
+    KeepPlaying,
+    /// Swap the video stream for an audio-only one and keep playing.
+    HandOffToAudio,
+    /// Stop making sound. The user did not ask for background playback.
+    Pause,
+}
+
+/// Decide what backgrounding should do.
+///
+/// * `is_video` — whether the current item has a picture to lose. Music is
+///   never paused by backgrounding; that is what a music player is for.
+/// * `background_audio_armed` — the per-player toggle (UR-040).
+/// * `in_picture_in_picture` — the app is not "gone", it is in a floating
+///   window and still visible. Pausing here would break PiP (UR-041).
+///
+/// TRACES: UR-040, UR-041 | DR-224 | UT-211
+pub fn background_action(
+    is_video: bool,
+    background_audio_armed: bool,
+    in_picture_in_picture: bool,
+) -> BackgroundAction {
+    // PiP first: the window is still on screen, so this is not backgrounding in
+    // any sense the user would recognise.
+    if in_picture_in_picture {
+        return BackgroundAction::KeepPlaying;
+    }
+
+    // Music has no picture to lose; a music player that stopped when the screen
+    // locked would be broken in an obvious way.
+    if !is_video {
+        return BackgroundAction::KeepPlaying;
+    }
+
+    if background_audio_armed {
+        BackgroundAction::HandOffToAudio
+    } else {
+        BackgroundAction::Pause
+    }
+}
+
+/// Whether a media type has a picture that backgrounding would throw away.
+///
+/// TRACES: UR-040 | DR-224
+pub fn is_video_media(media_type: MediaType) -> bool {
+    matches!(media_type, MediaType::Video)
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn video_without_the_toggle_pauses() {
+        // THE REPORTED BUG. Native video runs in a foreground media service that
+        // keeps playing when the app is hidden, and nothing paused it -- so
+        // locking the screen gave background audio to a user who never asked
+        // for it.
+        assert_eq!(
+            background_action(true, false, false),
+            BackgroundAction::Pause
+        );
+    }
+
+    #[test]
+    fn video_with_the_toggle_hands_off_to_audio() {
+        assert_eq!(
+            background_action(true, true, false),
+            BackgroundAction::HandOffToAudio
+        );
+    }
+
+    #[test]
+    fn music_always_keeps_playing() {
+        // Backgrounding a music player and having it stop would be absurd. The
+        // toggle is irrelevant here: there is no picture to give up.
+        assert_eq!(
+            background_action(false, false, false),
+            BackgroundAction::KeepPlaying
+        );
+        assert_eq!(
+            background_action(false, true, false),
+            BackgroundAction::KeepPlaying
+        );
+    }
+
+    #[test]
+    fn picture_in_picture_is_not_backgrounding() {
+        // The video is in a floating window and still on screen. Pausing would
+        // break PiP (UR-041), which is a separate feature reached through
+        // onUserLeaveHint rather than onStop.
+        assert_eq!(
+            background_action(true, false, true),
+            BackgroundAction::KeepPlaying
+        );
+        assert_eq!(
+            background_action(true, true, true),
+            BackgroundAction::KeepPlaying
+        );
+    }
+
+    #[test]
+    fn the_rule_does_not_depend_on_the_renderer() {
+        // There is deliberately no renderer parameter. The WebView path and the
+        // native path must answer identically -- the split between them is what
+        // produced the defect, because the toggle only ever reached one.
+        for armed in [true, false] {
+            let once = background_action(true, armed, false);
+            let again = background_action(true, armed, false);
+            assert_eq!(once, again);
+        }
+    }
+
+    #[test]
+    fn only_video_counts_as_having_a_picture() {
+        assert!(is_video_media(MediaType::Video));
+        assert!(!is_video_media(MediaType::Audio));
+    }
+}

src-tauri/src/player/mod.rs

@@ -4,6 +4,7 @@
 //         DR-001, DR-004, DR-005, DR-009, DR-028, DR-029, DR-047
 pub mod autoplay;
 pub mod backend;
+pub mod background_policy;
 pub mod events;
 pub mod media;
 pub mod queue;