fleetd #761: invariant 4 — a lead's own pane needs an empty input box

CLAUDE.md

@@ -74,6 +74,13 @@ and the sender silently receives nothing. Fail toward the recoverable error.
    re-send because a call looks slow — the bridge delivers when the peer is `idle`, `blocked` or
    `done`. A spawned member must **also** have mounted the bridge MCP: until it has, it is not
    deliverable, and a send waits on that gate for ~60s and then fails without ever reaching its pane.
+   **A lead's own pane has a second gate: its input box must be empty.** The multiplexer pastes and
+   submits in one step, so a delivery that lands while the operator is typing submits their
+   half-written line. A heartbeat, a ticket nudge and lead-to-lead mail therefore wait until the box
+   is clear, and a pane the daemon cannot read as a box waits too. Nothing is lost — every one of
+   those paths retries — but a lead that leaves text sitting in its box receives nothing until it
+   clears, and the only sign is one warning in `fleetd.out` after 20 held checks in a row. Delivery
+   to a *member* is not gated this way, because nobody types in a member's pane.
 5. **Never move a fleet session, pane or peer except through the bridge.** The bridge owns policy;
    the multiplexer owns PTYs. Any route that changes fleet state without the bridge's checks
    bypasses every rule above — the `herdr` CLI and its socket are the usual example.