Give the message verb a permission mode, so rework sessions can report

[MJohnson459]

Assert the permission mode every prompted launch depends on

The flag the task asked for was already there. --permission-mode auto reached
the built-in claude message template in commit 88d6e30 (#155's
capped-session recovery work, merged 2026-08-14 14:30), which needed it for the
same reason — the nudged turn does real work. What was missing was anything
holding it there: no test named the flag, and DESIGN.md discussed it only inside
the capped-recovery paragraph, where it reads as a property of that one feature.
So this change supplies the parts of the task that were genuinely absent.

A test. every_builtin_claude_launch_that_prompts_carries_a_permission_mode
asserts, over the built-in templates, that every verb handing an agent a prompt
— dispatch, plan, message — carries both {prompt_file} and
--permission-mode auto. Removing the flag from the message line fails it
with the offending template printed; confirmed by doing exactly that before
restoring.

The resume decision, made deliberately rather than by omission. resume
keeps no permission mode, and the same test asserts it carries neither a mode
nor a prompt. That is the distinction worth encoding: resume starts no work of
its own, it reopens a session in the operator's own terminal, where the ask-mode
default is answerable by whoever is sitting in front of it.

DESIGN.md §8 gains a paragraph — a permission mode is a property of a
launch, not of a verb — stating the rule, naming resume as the deliberate
exception, and, more importantly, naming the failure's signature: a session
refused its edits and its commands cannot run voro done, so it exits having
done real work Voro never hears about, reconcile finds the process gone, and the
task lands in stalled. A missing launch flag therefore surfaces as a dead
agent, sending the operator to liveness (#376, #390, #135 — all working) rather
than to the launch that could not act. The capped-recovery paragraph now refers
to that rule instead of restating it, and the code comment on BUILTIN_AGENTS
picks up the same stall symptom.

Verification

cargo test --workspace (835 tests) and cargo clippy --workspace --all-targets -- -D warnings both pass; cargo fmt --all applied.

Verified at the real surface, against an isolated scratch store and a scratch
git project, using a target/debug build of this branch:

1. Dispatched a fixture task to the built-in claude agent; the session
   committed its work and reported with voro done, landing it in review.
2. Rejected it with feedback through the cockpit's a key — the path that
   frames the feedback with rework_message and sends it. The launch log
   records the real command: claude -p --resume 'b0625130…' --fork-session --session-id '2d28d55e…' --permission-mode auto "$(cat …)".
3. The forked session edited GREETING.md, amended the commit, ran git show --stat HEAD, and ran voro done — landing the task back in review with
   its rework summary, and no permission refusal anywhere in its log. Each of
   those three is a thing the pre-fix session on task 307 reported it could not
   do.

Follow-up filed

Task #449 (voro, discovered from this one). Verification turned up a second,
independent rejection path with the same misleading symptom: the transition
menu's own reject with feedback entry, and the voro reject CLI verb, only
move the state — they send nothing. For a supervisor-owned agent that cannot end
anywhere but stalled, and it gets there inside the same keypress, since
apply_and_refresh reconciles immediately afterwards and reads the finished
session as dead. Observed live during this verification. It contradicts §8's
claim that review keeps the session open "so a reject-with-feedback returns
the work to it", so the proposal lays out the choice rather than assuming one.