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>

echolot-prober/app/build.gradle.kts

@@ -15,7 +15,7 @@ android {
         targetSdk = 35
         // Bump versionCode on EVERY deployed change — it is shown on screen and lands in the
         // JSON report as proberBuild, so a report is attributable to an exact prober build.
-        versionCode = 3
+        versionCode = 4
         versionName = "0.1.0"
     }