prober build 4: newProcess fallback when the Shizuku UserService won't bind

Build 3 settled it: the Lenovo TB330FU/A15 never spawns the UserService
(two 25s bind attempts, binder alive, permission granted). Build 4 falls
back to the legacy Shizuku.newProcess remote-process API via reflection
and records exec_path in the evidence — whether that path works per
device is itself the capability question core-shizuku needs answered.

Also archives both build-3 reports: phone 7/7 incl. provoked NEIGH
transitions in ip_monitor; traceroute.udp4 handled a silent hop ("*")
correctly on both devices.

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

docs/build-status.md

@@ -132,6 +132,13 @@ Archived as `…-build2.json` in `echolot-prober/reports/`. The findings:
 - Tablet Shizuku: binder alive, permission granted, but UserService bind timed out (0/7) —
   first-spawn dex extraction on slow storage suspected; build 3 raises the bind window to
   25 s + one retry. Phone stays 7/7 with rich neighbor/RA/DHCP evidence.
+  **Build-3 verdict: not timing.** Both 25 s attempts timed out (50 s total) — the UserService
+  spawn genuinely fails on the Lenovo/A15. Build 4 adds a reflection fallback to the legacy
+  `Shizuku.newProcess` remote-process API when the bind fails; `exec_path` in the evidence says
+  which path ran. Whatever the outcome, core-shizuku must not assume UserService works
+  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.)
 - `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.