docs(handoff): RESOLVED — vps2 daemon degradation was the mesh blocker; privatization withdrawn

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

docs/HANDOFF-2026-07-23-companion-apk-deploy.md

@@ -126,3 +126,26 @@ Chain of findings, each verified live:
   broader public mesh.
 - **Upstream:** report the direct-peer session-path asymmetry to
   jmcorgan/fips (0.4.1).
+
+## RESOLVED — root cause was vps2's degraded daemon, NOT the public tree (23:45)
+
+The privatize-the-mesh recommendation above is WITHDRAWN. Final diagnosis:
+vps2's fips daemon (3 days uptime, 0.2% CPU, idle box) had internally
+degraded — EVERY link it carried showed ~4.5 s RTT (even to peers 30 ms
+away), and since the anchor sits on the phone↔node path, everything through
+it inherited that. `systemctl restart fips` on vps2 restored link RTTs to
+40–340 ms, and anchor→node mesh HTTP went from 14–17 s (intermittent hard
+fails) to a steady **165–275 ms**. Node↔node direct sessions were always
+fine (.116→framework-pt ULA HTTP: 894 ms cold, sub-second warm) — the
+user's read was correct.
+
+Actions taken: dead legacy anchor (185.18.221.160) removed from
+framework-pt + .116 seed files (fleet keeps vps2 + public-mesh membership
+via vps2 — we stay in the open mesh); fresh daemons on both nodes;
+**vps2 fips now has RuntimeMaxSec=1d + Restart=always** so a wedged anchor
+daemon can never rot for days again. Report the slow-degradation behaviour
+upstream (jmcorgan/fips, 0.4.1): long-running daemon in a ~1400-node mesh
+accumulates multi-second link latency at idle CPU, cleared by restart.
+
+Phone side: vc25's 60 s probe + pre-warm now has a millisecond-latency mesh
+to work with. Ready for the user's 5G test.