android: the lock-screen card, moved to media3 before anything is built on it

The card Kyle sees every day was a hand-built MediaStyle notification over a
MediaSessionCompat, on `androidx.media`, deprecated since May. Android Auto
needs a media3 session to browse, so the choice was to write the new thing
against a deprecated library or to move the old thing first; this moves the
old thing and adds no Auto. `MediaService` is a `MediaSessionService` and a
new `SoulStreamPlayer` is the `SimpleBasePlayer` media3 asks for when the
engine lives somewhere else — rodio, in Rust, behind a WebView round trip —
so `getState()` is a pure read of the last `NowPlayingArgs` off the bridge,
queue window and all, and every button routes back out through `MediaHub.act`.

Three corrections to the plan, each the kind that only shows up on a phone.
media3 **1.10.1**, not 1.11.0, whose POM drags kotlin-stdlib 2.2.10 into a
project that compiles with Kotlin 1.9.25. The audio-focus and becoming-noisy
blocks STAY hand-rolled: `setAudioAttributes(…, handleAudioFocus)` is an
ExoPlayer convenience that lands in a `@ForOverride` method which throws, and
deleting them would have lost "another app takes the output" and "headphones
out" with nothing failing anywhere. And the service is BOUND, never started —
`MediaSessionService.onStartCommand` returns `START_STICKY` without promoting
for any intent that is not media3's own, so a `startForegroundService` would
arm the ten-second kill timer and satisfy nothing, which is the 2026-09-13 bug
in a new coat. Four more things are load-bearing and silent when they break: a
playlist that must never be empty while a track exists, `COMMAND_GET_TIMELINE`
with `COMMAND_GET_CURRENT_MEDIA_ITEM`, `STATE_READY` while paused, and both
spellings of next and previous. Each ends in a card that is simply never
posted, with nothing in any log. The window carries `queueBase` now, for a
stable media-item uid as it slides, and `repeat`, whose numbering is swapped
between the app and media3, so that what a controller is told about repeat is
the truth and media3's own view of the end of the queue agrees with the
`hasNext` the next button is advertised on.

The 2026-09-13 bug has a second door, and `onStartCommand` is what shuts it.
media3 hands the framework a media-button `PendingIntent` built with
`PendingIntent.getForegroundService`, unconditionally, because the receiver the
legacy stub resolves is now this service — there being no `MediaButtonReceiver`
left for it to find. So the SYSTEM starts this service in the foreground on
every media KEY, while media3 promotes only for a session it calls
user-engaged. A key into a process built for that key, a key on a card paused
past the ten-minute tail that does not start playback, any key with the bar
cleared: none of them qualify, and each would take the app down ten seconds
later. (The card's own buttons are milder — only play/pause, and only while
paused, is a foreground start.) So `onStartCommand` promotes first, the way
this service always did — through media3's own `onUpdateNotification` when
there is a card to post, and otherwise with a plain notification of its own,
posted and withdrawn in the same breath. `Service`'s
`startForeground` is final, so the split is by what media3 can be asked to do,
not by watching it.

The walk gains `one-card` and `one-session` — the only checks that tell a
landed migration from a doubled one — plus an advisory `media-plumbing` line;
the logged window grew `base` and `rep`, which are the only readback either
field has anywhere on the device and which `queue-window` now asserts; and the
paused-restore wait goes to 25 s, which ANDROID.md had already claimed in one
place and contradicted in another. ANDROID.md also says plainly what the walk
cannot prove and Kyle has to try himself: headphones out, another app taking
focus, the card's actual look, and a Bluetooth headset's own buttons. The
Kotlin is unbuilt — no Kotlin compiler here — and was read against javap of
media3 1.10.1 and the real sources of `SimpleBasePlayer`, `MediaSessionService`,
`MediaNotificationManager` and `DefaultMediaNotificationProvider`; the manifest
and resources compile and link under aapt2, and the Rust type-checks.

crates/tauri-plugin-media-session/src/lib.rs

@@ -44,12 +44,11 @@ pub struct NowPlaying {
     /// The queue around what is playing: the current item and up to ten
     /// either side, rebuilt on every update.
     ///
-    /// NOTHING READS IT YET, and that is the point — `MediaService` ignores
-    /// both of these fields, so the card is exactly the card it was. media3's
-    /// `SimpleBasePlayer.getState()` wants a playlist and an index into it,
-    /// and when that migration comes the data it needs should have been
-    /// running on the phone for a while rather than have been written the
-    /// same day.
+    /// Round forty-eight is where this BECAME the card. `SoulStreamPlayer`
+    /// is a media3 `SimpleBasePlayer`, its `getState()` wants a playlist and
+    /// an index into one, and this window and `queue_index` are exactly that
+    /// — so what the lock screen shows is built out of these fields rather
+    /// than beside them.
     ///
     /// A CAP, not a length: a two-thousand-track queue crosses the bridge as
     /// twenty-one entries exactly like a twenty-one-track one does.
@@ -58,6 +57,22 @@ pub struct NowPlaying {
     /// Where the current item sits IN `queue` — not in the whole queue.
     /// `None` when the window is empty.
     pub queue_index: Option<u32>,
+    /// Where `queue[0]` sits in the WHOLE queue. A media3 `MediaItemData`
+    /// uid is built from it, so an entry keeps its identity as the window
+    /// slides past it and a track change is ONE media-item transition
+    /// rather than twenty-one re-labelled rows; it is also half of the
+    /// mapping Android Auto needs to turn a tapped queue row back into
+    /// `playQueueAt()`. `None` when the window is empty.
+    pub queue_base: Option<u32>,
+    /// Repeat, in the app's own numbering: 0 off, 1 all, 2 one. media3
+    /// numbers them 0 OFF, 1 ONE, 2 ALL — SWAPPED — and the Kotlin side
+    /// maps across rather than casting, which would turn repeat-all into
+    /// repeat-one. It crosses at all so the player's state is not a lie to
+    /// whatever reads it — the system's own media controls now, Android
+    /// Auto later — and so media3's view of "is there a next item" agrees
+    /// with the `has_next` the card's next button is advertised on.
+    #[serde(default)]
+    pub repeat: u8,
 }
 
 fn yes() -> bool {