fix(omp): coalesce fallback wakes while main handles claimed rows

[pranaypratyush]

Problem

When the OMP supervision branch is unavailable, fallback delivery can repeatedly inject FIRSTMATE WATCHER WAKE into main while main is already handling the same claimed, unacknowledged wake batch.

Each valid higher-sequence row can produce another priority operational interjection. OMP may then cancel or skip the tool call that was reading reports, reconciling current state, cleaning up completed work, or preparing the generation-bound acknowledgement. Main is sent back to fm-wake-drain.sh, the acknowledgement target advances, and another row can preempt handling again.

The durable queue prevents data loss, but it does not guarantee forward progress. A burst can therefore create a wake-drain loop that only a human interruption breaks.

Live evidence

Observed on 2026-08-31 in a live OMP 18.0.10 secondmate session while two scouts completed close together.

The supervision branch was unavailable. Every fallback notice included:

FIRSTMATE WATCHER WAKE: ...
(Supervision branch unavailable, falling back to main: the wake rows are already claimed by main)

The repeated command was:

bin/fm-wake-drain.sh

The bounded queue snapshots progressed as follows:

11 signal no-mistakes-open-pr-portfolio-triage-local-recovery.turn-ended
12 signal nsm-open-pr-portfolio-triage-local-recovery.turn-ended
WAKE_ACK_REQUIRED: ... --ack-through 12 ...

11 signal no-mistakes-open-pr-portfolio-triage-local-recovery.turn-ended
14 signal nsm-open-pr-portfolio-triage-local-recovery.status
15 signal nsm-open-pr-portfolio-triage-local-recovery.turn-ended
16 stale default:w1P:p2
WAKE_ACK_REQUIRED: ... --ack-through 16 ...

11 signal no-mistakes-open-pr-portfolio-triage-local-recovery.turn-ended
14 signal nsm-open-pr-portfolio-triage-local-recovery.status
15 signal nsm-open-pr-portfolio-triage-local-recovery.turn-ended
16 stale default:w1P:p2
17 stale default:w1Q:p2
WAKE_ACK_REQUIRED: ... --ack-through 17 ...

Between snapshots, OMP rejected in-progress report reads and current-state checks with:

Skipped due to pending system advisory.
Skipped due to queued user message.

Both scouts had already written valid terminal reports. No queue row was lost; the failure was handling starvation before acknowledgement.

Why this is distinct from #74

#74 tracks stale advisory prose that remains deliverable after newer durable state supersedes it. Its freshness reconciliation decides whether an advisory is still semantically current at the final delivery boundary.

This defect occurs when every row and notification is current. The problem is reentrant control-plane delivery while main is actively handling a claimed batch. Suppressing stale prose would not prevent a new valid signal or stale row from injecting another fallback turn and preempting the handler.

The two fixes may share delivery identity machinery, but they need separate invariants and regression scenarios. This issue is related to, not a duplicate of, #74.

Expected behavior

• At most one OMP fallback wake notification is in flight for main during one active handling episode.
• Main-owned rows appended during that episode remain durable without injecting another operational turn that preempts current handling.
• After acknowledgement, exactly one successor notification is delivered if unread main-owned rows remain.
• If the final drain snapshot includes the newer rows and acknowledgement consumes them, no redundant successor is delivered.
• Real captain messages retain priority and are never coalesced with operational wake notifications.
• Per-actor row ownership, branch grants, recovery generations, interruption replay, and no-lost-wake guarantees remain unchanged.
• Delivery failure before confirmed acceptance remains replayable without opening duplicate accepted turns.

Regression scenario

1. Make the supervision branch unavailable so one task-local wake falls back to main.
2. Let main claim and drain the row, but keep its handling episode open and unacknowledged.
3. Append additional valid signal and stale rows and run the normal watcher fallback path for each.
4. Assert that no second operational injection or main turn preempts the active handler.
5. Drain once more within the same handler and acknowledge the latest aggregate sequence.
6. Assert that no successor is delivered when the queue is empty.
7. Repeat while leaving one higher-sequence row unread at acknowledgement and assert that exactly one successor is delivered.
8. Inject a real captain message during handling and assert that it still interrupts normally.

Acceptance criteria

• A typed, actor-scoped notification-in-flight or equivalent coalescing identity covers the OMP main fallback boundary.
• Higher-sequence rows remain durable while a fallback notification is already accepted and being handled.
• Reentrant fallback offers cannot repeatedly cancel the handler's active tool call.
• Completion and acknowledgement cause zero or one successor notification based on unread main-owned rows.
• Failure and indeterminate acceptance cannot lose a row or duplicate an accepted main turn.
• Deterministic tests cover signal bursts, stale bursts, mixed rows, branch-unavailable fallback, acknowledgement races, genuine captain interjection, and restart recovery.
• Live OMP verification records the fixed burst behavior on the installed runtime.