Starvation notice promises an automatic ESC/Ctrl+C that cannot fire for a busy agent

[pseudoseed]

The starvation notice tells the operator that Tower will act automatically. In the case the
notice actually fires in, it will not.

What the notice says

mailbox-wiring.ts:280 and :297:

Tower sends one automatic Ctrl+C after the starvation window. If it remains held, ...
... Tower sends one automatic ESC after the starvation window. ...

Stated unconditionally, in both the Ctrl+C and the ESC variant.

What happened

builder-bugfix-189 (opencode harness), one architect message, Tower log:

16:22:09 Message held (busy): architect → builder-bugfix-189 (mailbox 739ebec1...)
16:23:10 [mailbox] ESCALATED 739ebec1… (held 60s, reason busy) — visibility only, not delivered
16:25:10 [mailbox] STARVATION notice → main about builder-bugfix-189 (1 held ~180s, reason busy)
16:25:35 Interrupt (ESC) sent: architect → builder-bugfix-189 ← me, by hand
16:25:36 [mailbox] delivered 739ebec1-…

No automatic control byte appears anywhere. The message sat 3m26s and moved only when a
human sent the same ESC the notice had promised.

Why it cannot fire here

mailbox-delivery.ts recordStreak, the auto-recovery arm:

const token = `${session.bytesWritten}:${session.info.cols}x${session.info.rows}`;
const current = this.recoveryState.get(key);
if (!current || current.detail !== outcome.detail || current.session !== session
 || current.token !== token) {
 this.recoveryState.set(key, { ..., since: now, attempted: false }); // clock RESET
} else if (!current.attempted && now - current.since >= this.recoveryMs) {
 ... recoverHeld(...) // the promised byte
}

Its own comment states the intent plainly:

Input alone does not advance this counter, but ANY app output does. Requiring the same
session + output token for the whole window prevents an unreadable ACTIVE turn from being
interrupted merely because its classifier detail stayed the same.

An agent that is busy is, by definition, producing output. Every pass changes bytesWritten,
which resets since, so now - since >= recoveryMs is never reached. The condition that
raises the notice (reason: busy, an agent working and rendering) is the same condition that
guarantees the recovery will not fire.

The guard itself is right and should not change. Interrupting a live turn because its screen
is unreadable is the wrong trade. The defect is entirely in what the operator is told.

Why this is the house defect class

This program keeps finding one shape: a claim about something, asserted where convenient and
never checked against the thing itself. Usually it is "I could not tell" spelled the same way
as "no". This is the inverted twin — "I am handling it" printed where the code has decided not
to. An operator who believes the sentence waits for a repair that is structurally unreachable,
and the held message is the architect's correction to a builder that is meanwhile committing to
the wrong fix.

Suggested fix

Derive the sentence from the same predicate the code uses, rather than restating a behaviour
next to it:

• If the screen has been static for the window, say the automatic byte is coming.
• If the agent is still producing output, say so, and say the operator's own
  afx interrupt <id> --no-enter is the remedy — because it is the only one.
• Do not print one unconditional sentence covering both.

The general rule this program has landed on twice already applies exactly: make a guard
report its own reach. A notice that cannot tell the operator whether its remedy applies
should not claim the remedy.

Related: #179, #180 (same defect class, different subsystem).