Watcher pause cadence resets when a live paused pane redraws

[withally]

Problem

A crew with a current paused: or verified captain-held status can re-enter the normal stale-wake cadence whenever its pane hash changes.

pause_state_class re-reads backend liveness on every evaluation. For a live agent it returns none; the caller then clears pause tracking, including the long-cadence marker and throttle. The next stable pane hash consequently surfaces another bare stale: wake even though the declared wait never changed.

Expected behavior

The liveness check should be one-shot per declared wait. After the initial inspection, the declaration should retain the bounded pause cadence across pane redraws, declaring status appends, watcher restarts, and a live agent. A new needs-decision:, blocked:, or done: line must still wake immediately.

Existing fix

We carry a focused fix in withally/firstmate@c735ec1, merged in the fork through PR #67. Its regression reproduces five stale wakes across five churning-pane watcher restarts before the fix and one bounded initial inspection after it, while pinning the captain-relevant wake boundary.

Happy to open that change as a focused upstream PR if wanted.

[kunchenguid]

Speaking as Kun's firstmate:

Inspected current main at 7b88520 (#2858). The pause cadence still resets when a live paused pane redraws. No comments, no linked upstream PR.

Evidence on bin/fm-watch.sh pause_state_class (656-710):

• After the declared-wait gate, it re-reads backend liveness on every evaluation (fm_backend_agent_alive, lines 672-676 and 688-694).
• For a live agent it returns none and deletes the long-cadence marker.
• Callers treat none as "clear pause tracking" (e.g. 1345-1348, 1474-1477). clear_pause_tracking drops the long-cadence marker and throttle.
• A pane hash change (redraw, status append, watcher restart) then takes the non-stable-hash path (1462+) and, with tracking gone, surfaces another bare stale: wake even though the declared paused: / verified captain-held wait never changed.

The header at 578-587 already says the re-surface age is anchored on the status-file mtime so a churny idle pane cannot reset the cadence. pause_state_class undoes that for any live agent. Expected: liveness is one-shot per declared wait; after the initial inspection the bounded pause cadence holds across pane redraws, watcher restarts, and a live agent. A new needs-decision:, blocked:, or done: line must still wake immediately.

VISION: mechanics bug. Aligns with scripts owning the mechanics, token efficiency (repeated stale wakes spend turns on an unchanged wait), and honesty under load (the declared wait is the truth; a redraw is not news). Authority, spine, vendor-independence, scope: not in play.

Related but not a fix: open PR #2867 touches pause_state_class only to switch last_status_line to last_general_status_line. It does not stop the live-agent none reset. Open PR #2877 is turn-end wake absorption (#2374), a different path.

Fork already carries a focused fix at withally/firstmate@c735ec1 (fork PR #67) with a regression that reproduces five stale wakes across five churning-pane watcher restarts before the fix and one bounded initial inspection after it. No competing upstream PR will be opened from this triage. The existing fork change is welcome as the upstream PR.

Labeling ready-for-pr.