docs(remote-agents): presence staleness bound is 180s since #3783

VISION_REMOTE_AGENTS.md

@@ -56,7 +56,7 @@ Remote agents solve it from the inside. Because the desktop retains no substrate
 
 **The body's state is mortal.** Files, checkouts, half-finished working trees — gone with the body unless the substrate persists them. The agent survives; its scratch space doesn't. Durable knowledge belongs on the relay, and agents are built to put it there.
 
-**Presence can lag the truth, but not for long.** If the substrate kills a body without ceremony, the presence dot can outlive the agent — by seconds if the connection drops cleanly, by at most about ninety if it doesn't. Presence is a lease the agent renews, not a flag it sets: a dead agent stops renewing and the relay forgets it. Ninety seconds of a wrong dot, never an indefinite one.
+**Presence can lag the truth, but not for long.** If the substrate kills a body without ceremony, the presence dot can outlive the agent — by seconds if the connection drops cleanly, by at most about three minutes if it doesn't. Presence is a lease the agent renews, not a flag it sets: a dead agent stops renewing and the relay forgets it. Three minutes of a wrong dot, never an indefinite one.
 
 **A running agent finishes on the configuration it started with.** New keys, new models, new settings take effect on the next body. And an instance that never got far enough to run — a body that failed to start — is the substrate operator's residue to clear, with the substrate's own tools. Editing an agent mid-sentence was never on the menu.
 

docs/remote-agents.md

@@ -203,17 +203,17 @@ one.
   deployment axis (`deployed`/`not_deployed`, from the stored
   `backend_agent_id`) is bookkeeping, not liveness. Staleness bound: presence
   can be wrong for the window between an abnormal agent death (SIGKILL, node
-  loss) and the relay's presence expiry — **90 seconds**
+  loss) and the relay's presence expiry — **180 seconds**
   (`PRESENCE_TTL_SECS`, `buzz-pubsub/src/presence.rs:16`; the vision's
-  "ninety seconds of a wrong dot, never an indefinite one"), the accepted
+  "three minutes of a wrong dot, never an indefinite one"), the accepted
   cost of M1.
   The Kubernetes binding minimizes the *avoidable* part of that window by
   sizing the termination grace period to the harness's full graceful-shutdown
   path (§K8s Grace). Two consequences the bound imposes: (a) the harness's
   presence-suppression knob, `BUZZ_ACP_NO_PRESENCE`, MUST join
   `RESERVED_ENV_KEYS` — locally the knob is cosmetic (the process and UI
   remain visible), but remotely M1 makes presence the *only* signal, so an
-  unreserved user env var would convert "wrong for ≤90s" into "wrong
+  unreserved user env var would convert "wrong for ≤180s" into "wrong
   indefinitely" and silently disarm the one bound in print; (b) presence is
   scoped to a **community**: the relay derives community from its host, so
   the deploy-time `relay_url` binds the body to one community for its whole
@@ -925,7 +925,7 @@ I5's enforcement point. A new harness knob:
   could disable the reaper and reopen unbounded lifetime through the front
   door. `BUZZ_ACP_NO_PRESENCE` (`config.rs:378`) MUST join in the same
   change, for the same shape of reason at I3 instead of I5: unreserved, it
-  lets user env silently defeat the 90s presence bound (I3). One knob
+  lets user env silently defeat the 180s presence bound (I3). One knob
   guards "knows when to leave", the other "you can see that it left";
   both are promises users must not be able to un-make by typo.
 - Distinctness note: this is a **fourth** timeout concept, deliberately named