Handler: retire notify-only, make the wrap-up durable, and unhook the comments from a missing spec

[bharathm03]

Three Handler follow-ups from the HF review: retire notifyOnly, give the
wrap-up summary a surface that survives the session, and stop citing a spec that
does not exist. Five commits, each independently revertible.

HF-3 — notifyOnly goes (6a32806b)

notifyOnly meant "tell me, never act": every pause escalated without spending a
judge call, and a park wake notified instead of typing continue.

Nothing in the product could turn it on. It was only ever sent as
defaultNotifyOnly, read from handler-config.json — a file the bridge and app
only ever read, never write. Hand-editing JSON was the sole path in, so the
mode was unreachable by construction.

Two engine branches go with it, and outputSnippet() behind them, which had no
other production caller. defaultNotifyOnly was that config file's only setting,
so the schema, its v1 migration, the loader, the engine's config cache and
cfg() go too. config.ts survives on ActivityRecord and appendActivity —
which is what a later judge or personality picker actually needs from it.

The accepted trade, stated rather than denied. Anyone who did hand-edit
that file has notifyOnly: true persisted in their handler-session record. Their
parked sessions will now inject continue into a terminal they had opted out of
auto-driving, and every pause will spend a judge call. Pre-v1, with no users,
that is worth more than a compatibility shim for a mode the UI never exposed.

One test is replaced rather than deleted: the notify-only sub-case was the only
thing asserting that a standing guard_blocked report is not a pending question,
and the park-wake gate reads exactly that predicate. It returns as a park-wake
equivalent.

Not done here, deliberately: the escalate-only empty state. Re-aiming the deleted
copy at escalate_only sessions is new product behaviour, and it belongs on its
own terms rather than inside a deletion.

HF-6 — the wrap-up outlives its session (bcaf544a, 43bfb37c)

The morning-after summary was composed from three private helpers, spent on one
push notification, and thrown away. The wrapped_up activity row kept only the
goal, which the app rendered nowhere.

That left the phone-was-off case with nothing at all: handler-activity.jsonl is
write-only, handler:activity is not a REPLAY_TYPE, and HandlerState is
never persisted — so an app that reconnected after the disarm had no feed to go
back to. Which is exactly when the summary is read.

A WrapUpRecord now persists in handler-wrapups.json and replays on
handler:status, already a REPLAY_TYPE. One module owns content selection so
the push body and the stored copy cannot drift. The app gains a pinned Wrap-up
section, and a project whose only remaining artifact is a wrap-up no longer
renders as "Handler is off".

The undo count is never frozen. It is an argument to the push renderer, not a
field on the record, and the app re-derives it. An undo taken after the wrap-up,
or a re-arm retiring the offers, would each make a stored count permanently wrong
on a card whose whole job is to be read later. The blocked count and its reasons
are frozen, deliberately — they die with the session when disarm drops it.
Freeze what dies with the session, never freeze what outlives it.

Sized for the wire it rides. handler:status is emitted twice per handler
event, held by reference in the replay cache, and crosses the relay to a phone.
Item text is clipped at 120 chars and five records are kept: a worst case of
~22K chars per frame, against the ~190K an uncapped shape allowed. The push
loses its "see the activity feed" tail, because that feed is not durable and
pointing at it was the bug.

Wrap-ups survive a re-arm. Snapshots are retired because each pins a stash, a
backup ref and a trash copy and owes a release(); a wrap-up owns no resource,
so retiring one keeps that cost and drops its reason.

HF-11 — comments stop citing a spec nobody can open (b98f0651, dcd36dcb)

~180 comments and 29 test names pointed at numbered sections of a handler spec —
§4.3, spec §5.2 — that is not in this repository and is not in its history.

Where the prose already carried the reason, the tag is simply gone. Where the
section number was the justification, the reason is written in from the code
that enforces it, naming a symbol a reader can grep: §5.4 becomes
instruction-scoped authorization and the file implementing it, §5.3 becomes the
HARD floor tier, §2.2 becomes the terminal states.

The 19 references that resolve are untouched: bridge/src/e2e/ and
packages/ cite docs/protocol/e2e-handshake.md by named section and that file
exists, plus two RFC citations. A path with a named section is a working pointer;
a bare number pointing at nothing is not.

No spec document was written to make the numbers resolve. Reconstructing one from
the code would invent a source of truth that never existed and leave ~180
comments citing a document written after them.

Review notes

An audit pass over the comment rewrites caught three fabricated invariants —
comments asserting rules the code does not have. Each was verified against the
source and corrected before commit:

• session_row.dart claimed the row body is the only affordance a stopped
  session has. There is a kebab Start at :678 whose handler comment says it is
  the same intent.
• session-store.ts invented a bound of "one disarmed session per upgrade".
  sessionPath is per-project-per-terminal, so an upgrade disarms every armed
  session.
• handler_reply_sheet.dart claimed the safety floor is the one class of block
  that always routes through a human. quickChoicesFor returns undefined for
  every guard_blocked; what is unique to the hard floor is that nothing lifts it.

Worth stating plainly: a comment-only change is invisible to every test here.
All 3159 bridge and 3087 app tests pass with those three false claims in the
tree, which is why they were hunted for directly.

Gates

• bun run --filter antgrid-bridge test — 3159 pass, 14 skip, 0 fail
• cd app && flutter test — 3087 pass
• cd app && flutter analyze — No issues found
• bun run typecheck — clean across all five TS workspaces
• npm run check:font-tokens — OK
• Line endings verified byte-by-byte per file; the four LF files stayed LF,
  everything else CRLF, none mixed.

Not verified: evals/tests/handler.test.ts was extended for HF-3 but the
eval suite was not run — it spawns real agents, relays and PTYs. Nothing yet
proves a wrap-up record crosses a real relay into HandlerState.

Unreviewed on a device: the wrap-up card renders every outcome group plus a
blocked line plus the undo line — up to a 7-line row, the tallest on the screen.
A deliberate call over a disclosure widget, but nobody has seen it on a phone.