android auto: a catalog row is handed to the app, not failed at

Every entry in a streamed playlist is `kind='stream'` with no file on this
phone — only a catalog id. A service-only process cannot turn that into audio:
the resolver is hundreds of lines of shared JS that exist while a WebView does
and not otherwise. So the car tapped those rows and nothing happened, which is
the worst of the three possible answers.

Now the process asks whether the APP can do it instead. Rust, finding nothing
local, reports WHICH playlist and entry were meant rather than just failing —
a catalog row is not a broken row, it is one this process cannot do alone, and
that difference is what decides between an error and a hand-off. Kotlin carries
it over `MediaHub.onRemote`, which is non-null only while the plugin is loaded,
which is only while a WebView exists: the same fact is both the channel and the
test for "is the app warm". And the JS plays it with `playFrom(playlist, items,
item)` — the exact call the half-sheet makes when the same row is tapped in the
app, so the queue, the provenance and the failure message are the app's own.
Nothing about the car is special once it arrives.

Cold, it says so instead of pretending: the focus is handed back rather than
held for silence, and the log names the row. A phone in a pocket genuinely
cannot play a Deezer id, and a tap that quietly does nothing is worse than one
that stops.

Two things the same change fixed on the way past. A streamed entry has no cover
FILE, only a remote URL, so `COALESCE(art_path, art_url)` gives those rows their
sleeves and a remote uri now goes to the host untouched instead of through a
FileProvider whose root check it could never pass. And Recent, playlists and an
artist's albums join Albums as GRIDS — all four are things known by the picture,
which is what the grid is for.

`probe.sh` gained `SS_KEEP=1`, without which the warm path cannot be tested at
all: the script force-stops SoulStream, which is precisely the app the hand-off
needs alive.

**Proven:** cold answers `auto cold, cannot resolve` and releases focus; warm
answers `auto hand-off to the app` and the event reaches the JS with no console
error. **Not proven:** that the audio then starts. Those Deezer ids have to go
through the resolver exactly as they do when tapped in the app, and if the app
cannot play them the car will not either — which is correct behaviour and
indistinguishable, from here, from a bridge that silently failed. It wants
checking with the app in front of you.

src/mobile/media.svelte.js

@@ -7,6 +7,8 @@
 import { invoke, addPluginListener } from "@tauri-apps/api/core";
 import { player, hooks, toggle, next, prev, seekSecs } from "./player.svelte.js";
 import { art } from "./art.svelte.js";
+import { playFrom } from "./playlists.svelte.js";
+import { listPlaylists, playlistItems } from "../lib/api.js";
 
 /* THE QUEUE WINDOW. Every update carries a bounded slice of the queue —
    the current item and QUEUE_WINDOW either side. Since round forty-eight
@@ -146,11 +148,41 @@ export async function bindMedia() {
                 case "prev": prev(); break;
                 case "seek": if (typeof p.position === "number" && p.position >= 0) seekSecs(p.position); break;
                 case "stop": if (playing) toggle(); break;
+                case "playRemote": playRemote(p.playlist, p.item); break;
             }
         });
     } catch {
         /* not a phone */
     }
+/**
+ * A row the CAR tapped that only the app can play.
+ *
+ * Android Auto can start this app with no UI, and a service-only process can
+ * play a local file but not a catalog one — that needs the resolver, which is
+ * here. So the car hands the row over instead of failing, and this plays it
+ * exactly the way tapping it in the app would: same `playFrom`, same queue,
+ * same provenance. Nothing about the car is special once it arrives.
+ */
+async function playRemote(playlistId, itemId) {
+    if (!playlistId) return;
+    try {
+        const pls = await listPlaylists();
+        const pl = (pls || []).find((p) => Number(p.id) === Number(playlistId));
+        if (!pl) return;
+        const items = (await playlistItems(pl.id)) || [];
+        /* item 0 means "the playlist", anything else is the row that was
+           tapped and the rest follows it — which is what playFrom's third
+           argument means. */
+        const at = Number(itemId) ? items.find((i) => Number(i.id) === Number(itemId)) : null;
+        if (!playFrom(pl, items, at)) {
+            player.error = "Nothing in “" + pl.name + "” can play yet.";
+        }
+    } catch {
+        /* a playlist that has gone, or a resolver that said no — the car has
+           already been told this row did not start. */
+    }
+}
+
     /* the card interpolates its progress from the last update; a top-up
        every half minute keeps a long track honest */
     setInterval(() => { if (player.track) syncMedia(); }, 30_000);