Mailbox reason and dismissal cannot express a thread-backed refusal, so the CLI promises a retry that never comes

[pseudoseed]

Two findings from #221's review that belong with #223's migration, not before it. Both are about
the same thing: the mailbox row's vocabulary cannot express what actually happened, so the route
picks the nearest word and the CLI repeats it as if it were checked.

1. Every non-delivered status is reported as held / no-live-pty

tower-routes.ts:2229 is const reason: MailboxReason = stored?.reason ?? 'busy', and the
delivery path holds nearly everything as no-live-pty. So afx send tells a user their message
is queued and will arrive when the recipient's session frees up — for a thread-backed row whose
backend is not initialised in Tower's process, where no session will ever free up because there is
no session.

The CLI promises a retry that will never come. That is worse than an error, because the user
stops looking.

2. dismiss() is documented as operator-initiated and now carries system refusals

mailbox.ts:413-418: "Transition a held row to dismissed (operator-cleared via afx inbox dismiss)". #221 made the delivery path call it for a --no-enter message to a thread-backed
agent, which is correct behaviour — the row can never be delivered and holding it raises a
starvation notice with no remedy — but it makes the docblock false, and a dismissed row now
means either "a human cleared this" or "the system refused it", with nothing distinguishing them.

That is the same defect class as everything else in that PR: one word for two facts.

The right shape, and why it is one change

Move the refusal to the SEND path. afx send --no-enter to a thread-backed agent should fail
at the CLI, where a human is watching and can act, rather than being accepted, queued, and quietly
terminated at drain time. The drain-time refusal then becomes an honest backstop for rows enqueued
before the recipient became thread-backed, rather than the primary mechanism.

That wants the same migration #223 wants: the reason vocabulary has to grow before either of these
can be reported truthfully, and dismissed needs a companion (or a discriminator) for
system-refused. One migration on the user-global global.db, not two.

Filed from #221's round-4 review; the architect's ruling was to keep #221 to proving #179 items 3
and 4 and the instrument bugs that made them unrunnable.

[pseudoseed]

The documentation belongs in this issue, and here are the files

#221 added two send outcomes that no document describes. Doing the docs here rather than in #221
avoids writing the vocabulary twice — but only if this issue actually carries them, so they are
named rather than left implied.

What is undocumented today:

• refused — the message will never be delivered and no retry is pending. Distinct from
  held, which promises a later attempt. Carries refusedReason, a sentence for a human rather
  than a MailboxReason. Today it has exactly one producer: a --no-enter message to a
  thread-backed agent, which a thread cannot honour because it has no composer.
• held with reason: null — held, and nothing has been refused. A thread submission in
  flight is the case that produces it. afx send renders it "pending". It exists because
  MailboxReason is three words about a PTY and not one of them describes any state a thread
  transport can be in — which is the vocabulary gap this issue is about.

Files that need it:

File	What it needs
codev/resources/agent-farm.md	The send-outcome vocabulary: delivered, held (+reason, including null), scheduled, refused
CLAUDE.md	The afx send section currently documents delivered / held only
AGENTS.md	Byte-identical twin — an edit to one that misses the other is its own defect
codev/resources/arch-critical.md	The mailbox-first invariant line names delivered/held; a third terminal outcome changes that sentence
codev-skeleton/resources/agent-farm.md	Adopters get the skeleton, not our instance
codev-skeleton/ twin of any other file above that exists there	Same rule: a framework change lands in both trees

Sequencing: if this issue's migration adds a fourth MailboxReason, the docs should be written
once, after it, describing the final vocabulary — not twice. That is the argument for doing them
here rather than in #221.

Filed from #221's round-9 review (claude lane).