android: the phone walk waits for the app, not just for the WebView

A walk always follows a fresh install, so the app is always cold: the shell
mounts, the library loads, Soulseek logs in and the share index is built.
Attaching only proves the WebView answers, and the walk used to begin its
first step there — against a page that had not finished mounting, which
reads as a broken feature rather than a slow boot. It now waits for the
handle it drives, and the attach itself gets two more tries when the
devtools socket outlasts its own forty seconds of patience.

tests/mobile/smoke.mjs

@@ -2290,6 +2290,23 @@ async function main() {
         steps = PHONE_STEPS; expect = PHONE_EXPECT; prefix = "phone-";
         still = phoneStill;
         console.log("attached to the phone's WebView (pid " + pid + ")");
+        /* A walk follows a fresh install, so the app is always cold here: the
+           shell mounts, the library loads, Soulseek logs in and the share
+           index is built. Attaching only proves the WebView answers — it says
+           nothing about the app being up. Starting anyway means the first
+           steps run against a half-mounted page and get reported as broken
+           features, which is exactly how an hour went once. Wait for the
+           handle the walk actually drives. */
+        const upFrom = Date.now();
+        let up = false;
+        while (Date.now() - upFrom < 90_000) {
+            try {
+                if (await cdp.evaluate(`!!(window.__ss && document.querySelector('.app'))`) === true) { up = true; break; }
+            } catch { /* a page mid-navigation answers nothing; ask again */ }
+            await sleep(1000);
+        }
+        if (!up) throw new Error("the app never came up on the phone (no __ss and no .app after 90s)");
+        console.log("the app is up (" + ((Date.now() - upFrom) / 1000).toFixed(1) + "s after attaching)");
     } else {
         if (!CHROME) throw new Error("Chrome not found");
         console.log("building dist-smoke/ …");