Handler: confirm the undo that leaves this machine, band escalations, answer the judge question before arming

[bharathm03]

Three Handler follow-ups from the HF review, each with its own tests.

HF-10 — the one undo that leaves this machine asks first

Snapshot undo has four actions. reset_hard, rm_rf and git_clean restore this checkout and nobody else's; force_push writes to a shared remote. The offer sits on a scrolling list row whose whole body is the tap target, so a thumb landing where the scroll stopped could overwrite a ref for everyone on it.

force_push now goes through AbConfirmDialog, naming the entry so the ref being overwritten is on screen. The other three stay one tap — the confirm is bought by blast radius, not by the word "undo". No promise of recovery in the copy: the bridge pins the current remote tip before overwriting, but only when the ref still exists there (snapshot.ts).

HF-5 — an escalation that stopped the agent sorts above one that merely waited

urgency was on the wire and observable only as an OS notification for a session you are not looking at (workspace_shell.dart:475 early-returns via _isViewingSession). Meanwhile the flat oldest-first sort filed a fresh blocking prompt under every stale question already on the list.

New compareEscalations in handler_state.dart: urgent band first, oldest-first within each band, age never crossing the band. An urgency a newer bridge invents ranks as normal — the safe band, since it claims nothing. Applied at both the status-replay sort and the live push (sorted on the way in: the push raises the toast, and the row the user came to answer would otherwise be at the bottom of the list they were sent to).

An URGENT chip rides _RowMeta, the only widget all three escalation row shapes share, so it cannot be added to two and forgotten on the third.

HF-7 — escalate-only is answerable before arming, not after walking away

ESCALATE ONLY was a post-arm chip you find by walking away and coming back to a session that woke you for everything. FocusedSessionCoverage now carries judgeCapable, and both pre-arm surfaces state it:

• the arm explainer body, on the watchable arm only (an unwatchable agent reports nothing, so what its judge could have done is moot, and a hedge under the stronger fact dilutes it)
• the shield tooltip in agent_panel.dart — the surface that answers every time. The explainer sits behind firstRunProvider.handlerArmedOnce, a once-ever global latch, while coverage is per-agent: a user whose first arm was a capable agent would meet an escalate-only one with no warning at all.

Precedence extracted as top-level handlerShieldTooltip so it is unit-testable without pumping the panel.

Review corrections

Three defects in the above, found by /code-review and each verified before accepting:

• the undo callback used unawaited, violating app/CLAUDE.md:41 — a discarded future's rejection reaches PlatformDispatcher.onError as a FATAL with no in-app frames. Now detached(...).
• latestEscalationId read escalations.last, which the new banding silently turned into "newest normal escalation, never an urgent one". Now folds on at.
• a compareEscalations doc claim that overstated where high comes from: the engine mints it itself for blocking prompts with no judge call, but escalate also passes the judge's own notify.urgency through, so a judge can author high on a routine question. The banding stands; the justification was too strong.

Gates

• flutter analyze — No issues found
• flutter test — 3026 passed, 2 skipped
• npm run check:font-tokens — OK
• bridge/ diff is comment-only, so no bridge run

Independent of #68 — both branch off development and touch disjoint regions of handler_service.dart.