FN-180's in-flight revoke watcher read `runAiMerge`'s own `status:"merging"`
stamp as a blocking pre-merge verdict: `merging`/`merging-pr` are members of
HARD_BLOCKING_TASK_STATUSES and daemon/dashboard/serve all wire the unoptioned
`getTaskMergeBlocker`. The merge aborted itself within the same second, the
drain catch cleared the stamp, and the sweep re-admitted the task every
`pollIntervalMs` forever. The abort branch spends no `mergeRetries`, so nothing
bounded the loop: no task merged, on any project, and no card was ever parked.
Fixed at both seams, because the watcher alone leaves the merge dying later:
- `ProjectEngine.wireTaskPauseMergeInterruption` evaluates the blocker against a
verdict view that neutralizes `isMergeActiveStatus` for the owned task.
- `assertMergeGateStillOpen` (merger-ai) re-reads the task from the store at the
ref-advance fence, so it observes the same stamp and revoked the very merge it
guards. Same neutralization applied.
Genuine verdicts still abort: failed/pending pre-merge step results, `paused`,
`needs-replan`, and the scheduler's `queued` (deliberately not neutralized —
MERGE_CONFIRMED_TRANSIENT_STATUSES would have swallowed it). A merge-active
stamp on a different task never enters the branch.
Replaces the FN-180 source-grep coverage with behavioral tests driving the real
production blocker through the handler. Proven differential: reverting the
neutralization fails exactly the `merging` and `merging-pr` cases (2 of 11).
Fusion-Task-Id: FN-184
5990ebb752