fix: let a declared pause outrank a busy pane's wedge escalation

[3264studios]

A crew that declares paused: <external wait> is meant to be absorbed onto the
bounded FM_PAUSE_RESURFACE_SECS cadence rather than treated as a possible wedge.
That holds while the pane is idle. It does not hold when the pane reads busy,
and a declared wait can legitimately hold a pane busy — a worker sitting on a
background monitor keeps a live foreground call for as long as the wait lasts.

Both consumers then re-escalate a healthy, correctly-declared pane every
FM_STALE_ESCALATE_SECS. Observed in normal operation as tens of repeat
"possible wedge" escalations against two declared-paused panes in a single
evening.

This is one defect at two call sites, which is why it is one PR: the watcher and
the away-mode daemon each reach wedge escalation without consulting the
declaration, and the review and documentation commits interleave across both.

Fix 1 — daemon: a declared pause outranks an enriched wedge escalation

Where it is today. bin/fm-supervise-daemon.sh:1216-1219 (on main).
handle_wake computes classify_stale's verdict at line 1216, then line 1219
unconditionally overwrites it with escalate whenever the reason matches the
watcher's enriched wedge shape:

decision=$(classify_stale "$arg" "$state")
case "$stale_detail" in
  idle\ *s,\ possible\ wedge,\ escalation\ *)
    decision="escalate|${reason#stale: }" ;;
esac ;;

The override exists so the daemon's cheaper status-log absorption cannot
re-absorb a wedge the watcher already analyzed. That is right for run-step and
pane state. It is wrong for a pause verdict, which is neither: it is the crew's
explicit declaration that the pane idles by design — the one cadence question the
wedge timer cannot answer for itself.

The override now yields to a pause verdict and nothing else. Every other
enriched wedge escalates exactly as before, including its
demand-deep-inspection detail.

Test evidence (tests/fm-daemon.test.sh, reverting only
bin/fm-supervise-daemon.sh):

	Result
without the fix	FAILS — not ok - paused enriched wedge escalated instead of using the pause cadence
with the fix	PASSES — 101 assertions, 0 failures

Fix 2 — watcher: a declared pause outranks a busy pane's wedge timer

Where it is today. bin/fm-watch.sh:1140 and bin/fm-watch.sh:1152 (on
main). Both busy call sites hand an over-age pane straight to
wedge_timer_check with no declared-pause check:

if [ "$busy_now" -eq 0 ] && busy_turn_over_age "$task"; then
  wedge_timer_check "$w" "$ssf" "busy (no completed turn)" "$ewf"

The idle stale paths above them already divert a declared pause to the bounded
pause cadence; these two never consult it. The nearest declared-pause check
(around line 1157) is gated on [ "$busy_now" -ne 0 ], so a busy pane cannot
reach it.

Both now route through busy_wedge_or_pause, which hands a declared pause to
handle_paused_stale and everything else to the unchanged wedge timer. Absorbed,
never silenced: the bounded recheck still re-surfaces the pause once per window,
and a later non-pause status line hands the pane straight back to ordinary wedge
detection. The gate is deliberately the cheap declared-pause read rather than
pause_state_class, which resolves a busy pane to working through run-step
precedence — the one verdict that cannot separate a wedge from a declared wait
here. It is skipped while afk is active, matching the other normal-mode pause
routing, so the daemon keeps owning triage there.

Test evidence (tests/fm-watch-triage.test.sh, reverting only
bin/fm-watch.sh):

	Result
without the fix	FAILS — not ok - a declared-paused busy pane wedge-escalated on round 1: stale: test:fm-busy-paused (idle 501s, possible wedge, escalation 1)
with the fix	PASSES — all three regressions green

The three regressions drive the real watcher over both busy branches (stable
hash, and the ticking footer that never repeats a hash) across repeated
over-threshold rounds, and pin the disconfirming cases alongside: a non-pause
verb still wedges, a lifted pause returns to wedge detection after a fresh timer,
and away mode still hands the wedge off.

Note on the test-conformance commit

The final commit adjusts those new regressions for main's generation-bound
downtime recovery. They stop a watcher deliberately between rounds; since that
recovery landed, an intentionally stopped cycle leaves it armed, so the next
round woke on check: rearm-resurface and exited before reaching the busy pause
divert. They now acknowledge each intentional stop with ack_stopped_cycle, the
same way the neighbouring busy-pane tests already do, with the queue assertions
ordered ahead of the acknowledgement that rewrites the queue.

Test suite

main is not green in this environment, so the bar used here is no new
failure, not a green suite. Baseline on untouched main, full suite,
141 scripts — 8 failed:

tests/fm-backend-orca.test.sh
tests/fm-bootstrap.test.sh
tests/fm-gotmp.test.sh
tests/fm-muse-harness.test.sh
tests/fm-pi-watch-extension.test.sh
tests/fm-remote-secondmate-lifecycle-e2e.test.sh
tests/fm-remote-secondmate-trace-context.test.sh
tests/fm-teardown.test.sh

Several are negative tests asserting an operation should fail, which succeeds
in this sandbox, so they look environmental rather than like real breakage on
main. None are touched by this change.

After this branch, the same full suite reports no new failure: the identical
set, minus tests/fm-bootstrap.test.sh, which passed this time. That one is
flaky rather than a stable pre-existing failure, which is worth knowing if you
use this list as a reference.

Two caveats stated plainly, so the number is not read as stronger than it is:

• tests/fm-watch-triage.test.sh reports a failure in both the baseline and
  the after run, for the same reason both times: it stalled under full-suite load
  and had to be unstuck, which fails the in-flight assertion. Run on its own it
  is green on both sides — 46 assertions on untouched main, and green again
  with this branch applied.
• tests/fm-secondmate-safety.test.sh and tests/fm-watch-arm.test.sh also
  stalled under load and were unstuck the same way. Both then passed.

Those stalls are the pre-existing hang described below, not a behavior change
here: the changed path fires only when a pane is busy, over the turn-age bound,
and under a declared pause, and none of those tests construct that. A
kind=secondmate pane is skipped before the busy branches
(bin/fm-watch.sh:1076), and fm-watch-arm.test.sh never declares a pause at
all.

bin/fm-lint.sh is clean (ShellCheck 0.11.0, the pinned version).

One environment caveat worth passing on: tests/fm-watch-triage.test.sh is
timing-sensitive under a loaded machine. Under the full parallel suite it can
stall in reap, which sends SIGTERM and then waits with no timeout — if the
watcher does not exit, the file hangs indefinitely. It passes standalone. That is
pre-existing and untouched here, but it is why the per-fix evidence above was
taken from targeted runs.

[3264studios]

Superseded by #3147 - closing this one.

Three things were wrong with this PR, and all three are fixed there:

• It was raised by hand, so it never satisfied the Require no-mistakes check.
  fix(bin): hand a busy declared pause to the away-mode daemon once, undecorated #3147 is raised through the pipeline with --fork-url, so the signature line and
  the v1 attestation are written by the tool and bound to the pushed head.
• It had gone stale. It is rebased onto current main in fix(bin): hand a busy declared pause to the away-mode daemon once, undecorated #3147.
• It was too broad. This PR bundled the watcher fix with two daemon-side
  changes that your own tests assert the opposite of. fix(bin): hand a busy declared pause to the away-mode daemon once, undecorated #3147 carries only the
  watcher fix; the two contested behaviours are raised as a question in Away-mode daemon: a busy pane overrides a crew's own declared wait in two places #3149
  instead of being changed here.

The watcher fix itself also gained a real correction on the way: the away-mode
handoff was keyed on the pane capture hash, which on a pane whose harness footer
ticks every capture would have re-fired every poll rather than once. It is now
keyed on the declaration, and the regression test drives a ticking pane apart from
a static one so that cannot regress silently.

Apologies for the noise on the first attempt.