android: the handoff — the pending rounds, the pipeline, and what is unverified

Everything written this session that has not been through the device: rounds 43
to 48 (each patch adversarially verified, 43's transient-notice expectation
fixed), a partial round 49, the pipeline scripts, the Android Auto design and
the icon comparison mock. Also the two harness changes that were never A/B'd —
adaptive waits, which may only shorten a declared wait and never lengthen it,
and a ship that runs the mock walk and the deploy at the same time. The A/B and
its 255-step baseline are in handoff/tools; main stays at what the phone has
actually walked.

handoff/rounds/ins-r48-walk-checks.txt

@@ -0,0 +1,36 @@
+
+            /* ── ONE card, and one session ────────────────────────────
+               The check that proves round forty-eight landed rather than
+               doubled. The card moved from a hand-built MediaStyle
+               notification over a MediaSessionCompat to media3, which posts
+               and owns the notification itself — and the way THAT goes wrong
+               is not a crash and not a missing card but two of them: two
+               notifications on the `playback` channel, two records in
+               `dumpsys media_session`, a stale duplicate in the shade and
+               media buttons arriving at whichever component the system
+               picked. Nothing above this line can tell one card from two:
+               `media-card` passes on the first `playback` record it finds.
+
+               `shadeNotice()` already returns every channel our package has
+               live, joined with `|`, so counting the `playback` entries is
+               the whole test — and it reads the dump `media-card` just
+               read, so it costs nothing and cannot disagree with the line
+               above it. */
+            const cards = cardNote.shadeChans.split("|").filter((c) => c === "playback").length;
+            const oneCard = cards === 1;
+            if (!oneCard) problems.push("EXPECT one-card " + JSON.stringify({ cards, chans: cardNote.shadeChans }));
+            console.log((oneCard ? "  ok  " : " FAIL ") + "one-card".padEnd(16) + " " + JSON.stringify({ cards }));
+
+            /* The same question of the system's own session list, and it
+               FAILS ONLY ON MORE THAN ONE. `dumpsys media_session`'s shape
+               is the one thing in this block that has never been held
+               against a real dump, so a count of zero means "I could not
+               read it", not "there is no session" — `media-session`, two
+               checks up, is what asserts that there IS one. */
+            const oneSession = !(sess.sessions > 1);
+            if (!oneSession) problems.push("EXPECT one-session " + JSON.stringify(sess));
+            console.log((oneSession ? "  ok  " : " FAIL ") + "one-session".padEnd(16) + " " + JSON.stringify({ sessions: sess.sessions }));
+
+            /* and the plumbing underneath it, read while something is
+               playing, printed and never failed — see mediaPlumbing() */
+            console.log("  --  " + "media-plumbing".padEnd(16) + " " + JSON.stringify(mediaPlumbing()) + "  (advisory: prints, never fails)");