A conversation fork's sleep outlives the fork and keeps the whole gate asleep #646

What's wrong

A conversation fork can call sleep, because forks inherit the template's tool surface (src/framework.ts:12484). The gate's sleep isn't scoped to the agent that set it:

• setSleep records the calling agent as sleepAgent (src/gate/event-gate.ts:1730-1735).
• While sleepUntil is in the future, evaluate() suppresses every non-privileged wake for every agent (:1055).
• When the sleep ends, only sleepAgent is woken (:1860-1861).

When the fork is swept or ended, nothing clears its sleep. disposeConversationAgent (:12626) is called from the idle sweep (:12760), from stop() (:3982) and from :19206, and none of these touch the gate's sleep. For the rest of that sleep, the primary and every other agent have their ordinary wakes suppressed. When the sleep ends, its self-wake is addressed to a name that is no longer registered, so it is dropped as agent_not_found (:13907).

Why it matters

A fork that sleeps and is then swept leaves the primary deaf to ordinary messages, and nothing tells the operator or the primary why.

There is also a design question underneath: the sleep is global while its wake is targeted, so even a live fork's sleep silences the primary.

Suggested fix

• In disposeConversationAgent, clear the gate's sleep when sleepAgent is the fork being disposed, e.g. with an EventGate.clearSleepFor(agentName).
• Separately, decide whether a fork's sleep should be gate-wide at all.

How it was found

Found by tracing R1-2 in the review of #634. The behaviour is the same on main (97ca7eba) without that PR.

Found during our review of #634: #634 (review)

_{Posted by the maintainer's desk assistant.}