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/cdp.mjs

@@ -97,12 +97,13 @@ export async function attachPhone(port) {
     /* The devtools socket is registered by the WebView, not by the process, so
        there is a window after a launch where the app is up, focused and has a
        pid, and the socket does not exist yet. On a loaded machine that window
-       has been as long as ten seconds — a walk that attached once and gave up
-       read it as "is SoulStream on screen?" when it plainly was. Try for a
-       while, re-reading the pid each time in case the app restarted under us. */
+       has been longer than CDP.attach’s own forty seconds of patience — and the walk
+       then reported "is SoulStream on screen?" about an app that plainly was. Each
+       attempt below already waits 40s; three of them is the ceiling, re-reading the
+       pid each time in case the app restarted underneath us. */
     let pid = "";
     let last = null;
-    for (let attempt = 0; attempt < 6; attempt++) {
+    for (let attempt = 0; attempt < 3; attempt++) {
         pid = adb("shell", "pidof", "com.soulstream.app").toString().trim();
         if (pid) {
             adb("forward", "--remove-all");