Deliver quick-messages by resume-after-rest-stop: one session, one name, no kill in the send path

[MJohnson459]

Quick-message delivery moves from fork-based to resume-after-rest-stop: Voro
releases a claude session once it has handed back, at rest in reconcile rather
than in the send path, and a quick message is then a plain in-place headless
resume. One session id, one name, one linear transcript for a task's whole life.

What changed

The built-in claude message verb resumes in place — claude -p --resume {session} --permission-mode auto ..., dropping --fork-session and
--session-id {new_session}. The {new_session} mechanism stays for fork-style
agents, and voro agent list still marks such a verb message(fork).

Reconcile gained the rest-stop arm (reconcile.rs::rest_stop). A task in
needs-input, review or waiting whose open session's listing entry reads
done has that session released through the agent's stop verb, best-effort,
through the same seam #433 stops at close. The row is untouched: it stays open,
stays the task's conversation, and no event or transition is recorded. The
done test is the guard — blocked is a turn still under way, and the handover
verbs fire mid-turn, so reading rest off task state alone would clip the tail of
the very turn that reported. An absent entry has nothing to release, and the
stop is idempotent, so firing on every pass converges rather than repeating.

The send path carries no unconditional stop. It gates on liveness as before,
and only where the target is still listed at rest — the operator outrunning a
reconcile tick — makes the same release inline and waited-on, refusing the send
outright if it fails so a message that could not land commits nothing.

The capped-session sweep (u) releases unconditionally. This was not in the
task as filed and was decided with the operator mid-task. A capped session's
supervisor is alive, so it reads blocked, never done, and no reconcile pass
will ever release it — while the hold that refuses an in-place resume sits right
there. The sweep cannot lean on the rest rule either: that rule's done test is
only sufficient because the liveness gate refuses every session it does not
cover, and the sweep has already walked past that gate on the strength of the
cap reading. Having stood down the guard that makes the test enough, the bypass
has to be complete. So nudge_one stops first, waits, and abandons the nudge if
the release fails. Two costs are priced in §8 rather than left to be found: a
wrong cap reading now kills a live turn where it used to cost a redundant one,
and the reading can be a minute stale, so a hand-restarted session can be
stopped from under the operator. Both are why the sweep stays on a keypress.

Docs. DESIGN.md §8 rewrites the fork passage: delivery is in-place resume
against sessions the rest rule has released; the rule, its mid-turn rationale
and the handed-back invariant are stated; fork delivery shipped, lived briefly
and was reverted because the session name is the operator's addressing scheme;
both stop and fork are back doors around the daemon's ownership model and the
verb swaps to the sanctioned front door when one exists; the agents-view trade
is recorded. The nudge paragraph and the session-lifecycle paragraph are
rewritten to match. docs/agent-integration.md documents all three stop
triggers and what each requires of the verb. CHANGELOG amends the two unreleased
entries this supersedes.

Verification

cargo test --workspace (872 tests) and cargo clippy --workspace --all-targets -- -D warnings both clean.

New tests: each rest state releasing once at the right reference with the row and
event log untouched; blocked, working, absent, running, refless and
stopless cases releasing nothing; the built-in verb rendering in place with no
{new_session} while a template carrying it still binds; the send path's inline
fallback firing only on a done-listed target, a failed release refusing the
send and committing nothing, and a confirmed send moving the pid with the
reference unchanged; the nudge releasing before it resumes, and a failed release
sending nothing. Each new arm was mutation-checked — disabling it fails the tests
that cover it.

Live check against a scratch db with a real claude --bg dispatch: the session
handed over, reconcile released it (its entry left the default listing; a
duplicate stop a second later exited 0), and two quick messages then landed back
to back with a voro done between them — both as claude -p --resume against
the same session id, no stop between them, the work of all three turns present,
one transcript file with no fork siblings, voro-1-write-hello.md intact in the
listing and in the transcript's customTitle, and A reopening the same
conversation with every turn in it.

One recorded assumption did not survive that run and is corrected in both docs:
a finished -p turn did not re-register the session into the default listing
on this version, so no second release was needed and none was made. The rule is
written to be indifferent either way.

Follow-ups filed

#452 — a cap is account-wide, so the sweep's per-session reset parsing
reconstructs one global boolean; the "still before its reset" tally says almost
nothing, and a weekly cap reads ready days early because parse_clock keeps only
the clock half of Aug 14, 9pm while reset_passed resolves it to the nearest
occurrence.

#453 — the cap fixture Session limit reached · Retrying in 5m ... attempt 2/10
is documented as observed but was read out of the agent's binary. Whether a
backgrounded session can actually sit in a retry loop decides whether the sweep
is stopping sessions that would have resumed themselves.