prober: build-4 tablet report — newProcess fallback works where UserService won't

exec_path confirms the Lenovo/A15 ran the whole battery via the legacy
Shizuku.newProcess path: 6/7 commands with real data, incl. Lenovo's
IpClient dump format (distinct from OnePlus's — the per-vendor parser
sample the prober exists to collect). Design consequence recorded:
core-shizuku needs a dual-path executor. ip_monitor times out under
newProcess; bind-wait shortening noted as future tuning.

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

docs/build-status.md

@@ -139,6 +139,16 @@ Archived as `…-build2.json` in `echolot-prober/reports/`. The findings:
   everywhere. (Phone build 3: still 7/7; `ip_monitor` now catches provoked NEIGH
   PROBE→REACHABLE transitions, and a mid-path router dropping one TTL round showed the "*"
   hop path works in traceroute.udp4.)
+
+  **Build-4 verdict (`…-build4.json`): the fallback WORKS.** Tablet Shizuku now SUPPORTED via
+  `exec_path: newProcess fallback` — 6/7 commands with real data (full neighbor table, per-netId
+  v6 route tables, Lenovo's IpClient dump — a distinctly different format from OnePlus's, i.e.
+  the per-vendor parser sample we wanted). **core-shizuku design consequence: dual-path executor
+  is mandatory** — UserService where it binds, newProcess where it doesn't; both confirmed live
+  on real hardware. Known rough edges: `ip monitor` times out under newProcess (subshell trick
+  doesn't survive that path); the 2×25 s bind wait before falling back is worth shortening once
+  a device is known-bad. Tablet UserService root cause still open — multi-user (3 users) is the
+  prime suspect; Shizuku app is current (13.6.0), so the stale-app theory is dead.
 - `ip_monitor` returned no events this run even with the provoked gateway ping (gateway was
   already REACHABLE, so no NEIGH transition happened). Evidence-dependent, not a bug.