android auto: the car's queue works like the page's, and every row gets its cover

"Needs the app" is gone. It named what the cold service could not do — the
resolver and the Soulseek session live in the page, and a car that starts
the app cold has no page — and Kyle's answer to the label was the right
one: a tap should find a copy and play it, in the background, and a
playlist should keep going through rows that are not here exactly as the
page keeps going.

headless_slsk.rs is a Soulseek session for a process with no page: the
stored account, one search (artist + simplified title, the server's
excluded phrases stripped), copies ranked by rules close to the page's
songCandidates — the title in the filename, streamable formats, a duration
within eight per cent, lossless over 320 over the rest, the artist in the
path, a free upload slot before anything else — and a download into the
same stream cache the page uses. Its own tokio runtime: a car-started
process has no Tauri one.

headless.rs is the page's queue in Rust. resolve_playable queues EVERY row
of a playlist in order, a row not here with its remembered peer file and
no path. The engine starts a row from its file when it is whole, from the
fetch already filling its cache file when one is, and otherwise finds it
on the network right then (the remembered peer first, then the search),
playing the bytes as they land; a peer that sends nothing for fifteen
seconds is dropped for the next copy, twice, and when a row has no copy
anywhere the queue moves on — only the last row's failure reaches the
card. The next three rows are fetched ahead of time, four seconds after a
start so nothing competes with the track that is starting, and when the
immediate next is whole before the current one ends it is appended to the
sink and the boundary is gapless — the page's preloadLocal and
preloadCachedStream in one. Fetches are keyed by cache file, not index, so
a shuffle cannot start the same file from the same peer twice. The card
shows the title at once with a spinner (STATE_BUFFERING through
headlessState), then the track; every source is remembered in the mirror,
so the row is "here" next time.

One session per process: when the app opens over it, login_inner ADOPTS
the client and reads its events through subscribe() instead of logging in
again — two logins from one address in quick succession is what the server
throttles — and the fetches in flight become the page's own preloads, so
the row the car was fetching ahead lands gaplessly under the page too.

Covers, always, like the desktop. Thirty of GhettoTechie's forty rows have
no catalog cover, and the car drew the app icon over them. In the cold
process the cover embedded in the file is extracted — the desktop's own
tagger::extract_art, keyed by the audio path under
<library>/.soulstream/stream-art/by-file/, a miss remembered as an empty
file — for browse rows, the card and the Continue row, and a row fetched
cold gets the same once 200 kB of it have landed. On the phone,
coverart.svelte.js is the desktop's playlist backfill as a background walk
over every playlist: the file before the catalog (the row's own cached
copy, persisted as art_path), then the ONE strict ladder the import review
uses (findCatalogTrack, persisted as art_url + track_id) — never a loose
name lookup. After boot, on every playlist change, every six hours, the
open page's rows first, a miss remembered for a day and only when the
catalog answered. The player does the same for the track that is playing
(ensureStreamArt: embedded, then catalog), makes the URL the entry's art
key and hands it to the walk to persist. The page's own hole is closed
too: a streamed row with no cover got no art key at all, and where it had
one the extractor's FILE PATH was stored where a data URL belongs; such
rows get a "stream:" key and the file is read as a thumbnail, and a stream
row's art_path now draws on the phone.

A car that starts the app cold has no page to walk for it, so the cold
process asks the catalog itself. cover_hunt.rs is catalogMatch.js in
Rust — the same Deezer field queries through the metadata crate, a match
only when the artist agrees, the base title agrees, the version
qualifiers are compatible and a known duration does not contradict; the
two are meant to stay in step — fed by every browse and every queue built
from a playlist. A blank stream row is answered from what was asked
before (stream-art/catalog.json, a miss for a day and only when the
catalog answered), else queued for one thread that looks rows up one at
a time behind the client's own Deezer pacing, writes the answer on the
row (art_url and the track id, only ever filling a NULL; the library is
WAL and the page's writer is another connection), and re-lists the
playlist on the car. The track that is playing gets the same, through an
entry that moves only the card's art and never its position. The cold
Soulseek search is the page's two-rung ladder as well: artist plus the
simplified title, then the title alone with the artist required in the
peer's path; the hunt's last rung is the page's last rung too, the
artist's whole shelf flattened to tracks, for the records the search
index buries — spent only on the track that is playing, bounded to forty
seconds, and the cover memory carries the matcher's version so a "no"
from an older matcher is no answer once a rung is added.

Two things the head unit found in the seam. media3's default onSubscribe
answers "not supported", so nobody was ever subscribed and the re-list
notice reached nobody; LibraryTree accepts subscriptions now, and covers
land on the car's list within seconds of being found. And the Soulseek
client spawns a download's transfer task with tokio::spawn, which needs a
runtime on the calling thread — the engine's resolver thread is not a
Tauri command, the spawn panicked, the thread died without a word, and
the card sat on BUFFERING; every client call from an engine thread runs
under the cold runtime's enter() now.

The phone's artist page never ran the MusicBrainz pass. It built its
discography from Deezer's list alone, so the releases Deezer's artist
listing omits — EPs, and whole albums — never appeared, nor the
authoritative release types or the guest-appearance and co-tenant
arbitration. The desktop's identity merge is a plain module now
(lib/artistIdentity.js, moved out of state.svelte.js verbatim, the
desktop importing it back), and the phone runs it after the page is on
screen — one implementation for both surfaces.

What the restarted head unit found, all in the seam between a car session
and the page — and one bug older than this branch.

The pump's calls into Kotlin never worked. "auto advanced to" has not
appeared in a single log while cold queues advanced through whole albums
under a card stuck on track one, and the new end-of-queue notice did not
fire either. FindClass on the self-attached pump thread resolves through
the system class loader, which cannot see com.soulstream.mediasession
.AutoNative; the lookup failed and the exception was cleared, silently,
every time. The class is taken from the object Kotlin hands every JNI
entry — on a Java thread, through the app's own loader — and kept as a
global reference; every pump call goes through call_auto_native.

Autoplay on connection worked unprompted and resumed Starboy at 3:50 of
3:50: the page writes the position one last time when a track runs out, so
a resume point can sit at the end. resume_queue treats a position within
two seconds of the duration as "the next item from the top", keeps every
entry (one not here is found on reach, like any other), and the headless
engine reports end-of-queue to Kotlin, which turns the card to paused. A
seek on the page reached the resume point only at the pump's next
five-second flush; seekSecs writes the session at once.

Opening the app over a cold car session handed the page the right queue
and the page called it a paused session that needed re-sourcing: the
transport snapshot it reads is built only from events after the page
subscribes, and an engine already playing sends no Playing. The bar said
paused, the card said PAUSED, the audio kept going. playback::init seeds
the snapshot from the engine's own progress when it adopts a running
engine, so the page follows what is sounding.

preview::init opened two more output streams at every launch for the
desktop's hover previews, which the phone never calls — three live AAudio
tracks on our uid with one sounding. It is gated off on Android.

ANDROID.md

@@ -1123,19 +1123,112 @@ The car binds `MediaService` with the app COLD — no Activity, no WebView, no
 it can, say what it cannot, and pick up where the phone left off. Four
 pieces, all of them landed 2026-09-18:
 
-**What plays cold.** Library tracks always did. Now a playlist's streamed
-rows play cold too, when their bytes are already on the phone: the page's
-memory of which peer file a catalog track resolved to
+**What plays cold: everything, the way the page plays it.** Library tracks
+always did. A playlist's streamed rows play cold too — every one of them.
+The page's memory of which peer file a catalog track resolved to
 (`soulstream.streamSources.v1` in localStorage) is mirrored to
 `<data>/stream-sources.json` (`stream_sources.rs`) — one entry every time a
 source is remembered, and the whole store once at boot for memories made
 before the mirror existed — and `auto_browse.rs` looks a streamed row up
-there, computes its cache file with the same hash `playback::cache_path`
-uses, and calls it playable when the file is byte-complete. Such a row is
-"artist · album" in the car; one that is not is "artist · needs the app",
-which is the amber-dot row of the design. A playlist's subtitle counts
-cached streams as "here". A tap on a row that needs the app is handed to
-the app when it is up (`playRemote`), exactly as before.
+there and computes its cache file with the same hash `playback::cache_path`
+uses. A row whose file is whole plays from it and carries the host's
+"downloaded" mark; a row whose bytes are not here is still a row that
+plays, and the difference is only that mark. `resolve_playable` queues the
+WHOLE playlist in order (`headless::PlayTrack.path` is `None` for a row
+not here, `stream` its remembered peer file), and the engine's queue
+(`headless.rs`) works like the page's: a row is FOUND when the queue
+reaches it — the remembered peer file first, else one search through the
+cold Soulseek session (`headless_slsk.rs`: the stored account, the
+server's excluded phrases stripped, copies ranked close to
+`songCandidates`, the best three tried with a fifteen-second first-byte
+watchdog) — the bytes land in the stream cache and play as they arrive,
+the next THREE rows are fetched ahead (`PREFETCH_DEPTH`, after the page's
+four-second start delay), and when the immediate next is whole before the
+current one ends it is appended to the sink for a gapless boundary
+(`Queue.armed`, checked again at the boundary). A row nothing on the
+network has moves the queue on, the page's rule; only the LAST row's
+failure reaches the card. The card shows the title at once with a
+BUFFERING spinner (`headlessState`) and the track once bytes play. One
+Soulseek session per process: when the app opens over a car session,
+`login_inner` ADOPTS the client (`headless_slsk::adopt` + `subscribe`)
+rather than signing in again — two logins from one address in quick
+succession is what the server throttles — and the fetches in flight become
+the page's own preloads (`PlayerState.preloads`), so the row the car was
+fetching ahead lands gaplessly under the page too. A playlist's subtitle
+counts cached streams as "here". A tap while the app is UP is still handed
+to the page (`AutoNative.describe` → `playMediaId`), which owns the queue
+then.
+
+**Covers, always.** The car draws the app icon over a row with no cover,
+and thirty of GhettoTechie's forty rows had none — pasted-tracklist rows
+the catalog never matched. Two hands fill them. In the cold process,
+`auto_browse::embedded_cover` extracts the picture from the file's own tag
+(the desktop's `tagger::extract_art`), keyed by the AUDIO path under
+`<library>/.soulstream/stream-art/by-file/` with a miss remembered as an
+empty file, for browse rows, the Continue row and the card; a row fetched
+cold gets the same once 200 kB of it have landed (`art_after_bytes`,
+re-notifying the card). On the phone, `coverart.svelte.js` is the desktop's
+playlist backfill as a background WALK over every playlist: the file before
+the catalog (`cachedStreamSourceFor` + `stream_embedded_art`, persisted as
+the row's `art_path`), then the ONE strict ladder the import review uses
+(`findCatalogTrack`, persisted as `art_url` + `track_id`) — never a loose
+name lookup, a blank tile beats another record's cover. It runs 25 s after
+boot, again when a playlist changes, every six hours, one row at a time,
+and the open playlist page's rows go first; a miss is remembered for a day
+in localStorage, only when the catalog answered. The player's
+`ensureStreamArt` does the same for the track that is playing (embedded,
+then catalog), makes the URL the entry's art key, and hands what it found
+to the walk to persist. Because everything lands on the ROW, the car —
+which reads rows straight out of the database — has it on the next browse.
+And a car that starts the app COLD has no page to walk for it, so the
+cold process asks the catalog itself: `cover_hunt.rs` is `catalogMatch.js`
+in Rust (the same Deezer field queries through the metadata crate, a match
+only when the artist agrees, the base title agrees, the version qualifiers
+are compatible and a known duration does not contradict — keep the two in
+step), fed by every browse and every queue built from a playlist: a blank
+stream row is answered from `stream-art/catalog.json` when it has been
+asked before, else queued for one thread that looks rows up one at a
+time behind the metadata client's own Deezer pacing, writes the answer on
+the row (`art_url`, and the track id; only a NULL is ever filled — the
+library is WAL, the page's writer is another connection), and re-lists
+the playlist on the car (`AutoNative.headlessCovers` →
+`notifyChildrenChanged`). The track that is playing gets the same through
+`art_from_catalog` / `art_after_bytes` and `AutoNative.headlessArt`, which
+moves only the art, never the position. The cold Soulseek search is the
+page's two-rung ladder too: artist + simplified title, then the title
+alone with the artist required in the peer's path. The hunt's last rung is
+the page's last rung as well — the artist's whole shelf flattened to
+tracks (`catalog_artist_track_candidates`), for the records the search
+index buries: Deezer's search answers "Nirvana Smells Like Teen Spirit"
+with six live takes and never the studio cut, while Nevermind's tracklist
+has it. That rung opens up to thirty tracklists behind the Deezer pacing,
+so it is spent only on the track that is PLAYING (`lookup(…, deep)`),
+bounded to forty seconds (a miss cut short by the clock is asked again
+within the hour, not the day), and never on a browse row — the search
+rungs answer those in half a second, and the phone's own walk, which does
+run the shelf rung, writes what it finds on the row for the car to read.
+The cover memory carries the matcher's version (`HUNT_VERSION`): a "no"
+remembered by an older matcher is no answer once a rung is added.
+
+**A trap that cost the first cold fetch.** The Soulseek client spawns a
+download's transfer task with `tokio::spawn`, which needs a runtime on the
+CALLING thread. The engine's resolver thread is not a Tauri command; the
+spawn panicked, the thread died without a word (a cold process has no
+stderr in logcat), and the card sat on BUFFERING for as long as anyone
+looked. Every client call from an engine thread now runs under
+`headless_slsk::rt().enter()`.
+
+**The artist page's MusicBrainz pass.** The phone built its artist pages
+from Deezer's list alone (`catalog_artist`), so the releases Deezer's
+artist listing omits — EPs, and whole albums (My Bloody Valentine had four
+releases) — never appeared, and neither did the authoritative release
+types or the guest-appearance / co-tenant arbitration. The desktop's
+identity merge now lives in `src/lib/artistIdentity.js` (moved out of
+`state.svelte.js` verbatim; the desktop imports it back) and
+`catalog.svelte.js` runs it after the page is on screen
+(`applyIdentity`: `catalog_artist_identity`, one retry after eight seconds
+on an empty answer, then `mergeArtistIdentity` into the page the screens
+already read). One implementation for both surfaces, on purpose.
 
 **Keep offline.** A playlist's More sheet has "Keep offline"
 (`src/mobile/offline.svelte.js`, the list in `config.json`
@@ -1175,9 +1268,9 @@ it over once, and `restoreSession` builds the bar from it — instead of
 restoring the page's own older session over live audio, which put the wrong
 title on the bar.
 
-**What the car is told.** A tap that cannot play — a streamed row with no
-cache copy while the app is cold, a hand-off the resolver refused, a row
-whose file is gone — used to be silence. `MediaHub.fail` now puts the reason
+**What the car is told.** A tap that cannot play — a streamed row no peer
+on the network has, a hand-off the resolver refused, a row whose file is
+gone — used to be silence. `MediaHub.fail` now puts the reason
 in the playback state (`STATE_ERROR` with the message, which Auto draws as a
 card) and sends a `SessionError` carrying "Open SoulStream" as the
 resolution action; the next track that plays withdraws it. The page reports