reports: build-5 runs on both devices — new toolchain is behaviour-neutral

TB330FU (A15/SDK35) and CPH2747 (A16/SDK36) both re-run on the AGP 9.2 /
Gradle 9.6 / Kotlin 2.2.10 / JDK 25 / targetSdk 36 toolchain. Every probe on
both devices keeps the verdict it had on the previous build (tablet vs build-4,
phone vs build-3), so the upgrade changed no observed capability.

Dual-path Shizuku executor now confirmed on the current toolchain on both:
phone exec_path=UserService, tablet exec_path=newProcess fallback, both 7/7.

Collection-loop gotchas recorded in build-status.md, found while driving the
phone over USB:

- icmp.ping6's verdict is topology-dependent, not build-dependent. A run with
  only 2 networks up reported UNSUPPORTED; with cellular present it is the
  expected "echo reply on cellular only". Always read it against
  link.snapshot's network_count from the same report.
- The Shizuku permission dialog times out after 30 s and the probe logs
  "permission not granted" at ~30027 ms. Grant it before starting a run.
- uiautomator dump can report a stale idle state right after a tap; the
  exported JSON's durationMs values are the ground truth for completion.

CLAUDE.md's collection loop is updated — over USB the run is fully driveable
via am start / input tap / run-as cat, no manual export needed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/build-status.md

@@ -167,11 +167,50 @@ registry. `git.rambossek.at/echolot/echolot-server:{v0.1.0,latest}` pulls anonym
 registry image → anonymous pull. Note the tag convention: image tags carry the bare version
 (`v0.1.0`), release tags the namespaced one (`server-v0.1.0`); selfupdate normalizes.
 
+## Toolchain upgrade + build-5 tablet re-run (2026-07-30)
+
+Moved to the laptop (USB adb — far more stable than wireless, as expected). Upgraded the build
+off the JDK-21 ceiling: **AGP 8.7.3 → 9.2.0, Gradle 8.14.3 → 9.6.0, Kotlin 2.0.21 → 2.2.10**,
+which lets the toolchain run on JDK 25. Two AGP-9 migration edits were required:
+- AGP 9 has **built-in Kotlin support**, so applying `org.jetbrains.kotlin.android` alongside it
+  fails with "extension with name 'kotlin' already registered" — the alias must be dropped
+  (`kotlin.compose` / `kotlin.serialization` stay; they are separate compiler plugins).
+- The `kotlinOptions { jvmTarget }` block came from that plugin and no longer resolves; AGP
+  derives jvmTarget from `compileOptions` instead.
+
+`compileSdk`/`targetSdk` 35 → 36, because Android Studio only ships API 36.1 by default and
+installing 35 was avoidable churn. **Build-5 re-run on the TB330FU is verdict-identical to
+build-4 across all 10 probes** (`…-build5.json`) — the toolchain jump and targetSdk 36 are
+behaviour-neutral on this device, including the `newProcess` Shizuku fallback (still 7/7,
+`exec_path: newProcess fallback`, UserService still never binds).
+
+Also of note: `traceroute.udp4` is SUPPORTED here (6 hops via errqueue, "no native shim needed"),
+which is what retires next-step 2 below — the JNI shim is not required on either known device.
+
+**OnePlus 15 build-5 re-run (`CPH2747-android16-sdk36-build5.json`): all 10 SUPPORTED, identical
+to build-3.** `exec_path: UserService` on the phone vs `newProcess fallback` on the tablet, both
+7/7 — the dual-path executor requirement is now confirmed on the current toolchain on both
+devices. Phone is on Android 16 / SDK 36, i.e. `targetSdk = 36` is also exercised natively there.
+
+Two collection-loop gotchas found while driving the phone over USB:
+- **`icmp.ping6`'s verdict is topology-dependent, not build-dependent.** A first run with Shizuku
+  stopped and only 2 networks up reported UNSUPPORTED; with cellular+wifi present it is the
+  expected SUPPORTED / "echo reply on cellular only — default network has no v6 path". Do not
+  read a ping6 verdict without checking `link.snapshot`'s `network_count` in the same report.
+- **The Shizuku permission dialog times out after 30 s** (`shizuku.command_battery` logs
+  `Shizuku permission not granted` at ~30027 ms). Screenshot→read→tap round-trips can exceed
+  that. Grant the permission *before* starting a run, or accept that the first run after a fresh
+  install burns the Shizuku probe; the grant is persistent, so the next run is clean.
+- The phone auto-rotates; tap coordinates must be recomputed per orientation, and `uiautomator
+  dump` can report a stale idle state right after a tap — trust the exported JSON's `durationMs`
+  values as ground truth for whether a run really completed, not the button label.
+
 ## Next steps
 1. Build locally, run on several physical devices (varied Android versions/vendors), collect the
    JSON reports — especially the real per-device Shizuku dump formats.
-2. If `trace.errqueue_reachable` = PARTIAL, add a C-over-JNI errqueue shim (`recvmsg`+cmsg parse)
-   as a `:native` module and a real `traceroute.udp4` probe.
+2. ~~If `trace.errqueue_reachable` = PARTIAL, add a C-over-JNI errqueue shim.~~ **Retired** —
+   SUPPORTED on both known devices; `traceroute.udp4` reads real hops via `Os.recvmsg` +
+   `StructMsghdr` reflection, so no `:native` module is needed.
 3. Start the Go server skeleton (enrollment + profile + sessions + UDP echo with observation
    blocks + canary-DNS reference records) per probe-protocol.md.
 4. Fold confirmed capabilities into the production `core-probe` / `core-shizuku` modules.