The merge queue's "red alone" mark on a pull clears when main moves, so a green pull rejoins without a new head #6506

The queue's red mark on a pull now records the base tip it went red on, and enqueue drops the mark when main has moved. The pull then gates again as a fresh entry. I ran tsc --noEmit and the queue, gate-last, stale-green, flow-gate and autonomy tests, and all passed. I did not run the full suite; the forge's check does that on this push.

• The mark: Remembered in src/checks/queue.ts has a new base field. Both places that set a mark fill it in from the candidate's base: red alone, and red on its own merge or on top of its candidate.
• The check: enqueue is now async. It reads the base branch tip with resolveOid, but only for a pull that has a mark, so the common path does no git work.
• Same head, same base: a mark that still matches keeps the pull out as before, gated alone after the fresh pulls.
• Different base: a mark whose base differs is dropped, and the pull rides in a candidate with the others.
• Unreadable tip: if the tip can't be read, the mark is kept.

Tests

• Two new tests in test/merge-queue-clash.test.ts: red alone, then main moves, then enqueue gates it fresh in one candidate with the next pull. And red alone with main unmoved, which is still re-checked alone after the fresh pull.
• Three existing tests assumed a mark survives a landing, which is the behaviour this issue removes. I changed their setup, not their intent:

- The two clash re-check tests now re-mark B on the current base before the re-check (markedNow). - The "red pull stays out" test in test/merge-queue.test.ts now expects the re-gate to ride fresh with c, and the red-batch rate there is "2 of 4" instead of "1 of 3".

Not done: the "red" land decision in src/crew/autonomy.ts still holds a pull out until its head changes, apart from the 30-minute re-gate. That is the ledger, not the in-memory mark this issue names, so I left it alone. If #5666's 36 hours also came through that path, it needs its own change.

Closes #6493

The queue's red mark on a pull now records the base tip it went red on, and enqueue drops the mark when main has moved. The pull then gates again as a fresh entry. I ran tsc --noEmit and the queue, gate-last, stale-green, flow-gate and autonomy tests, and all passed. I did not run the full suite; the forge's check does that on this push.

• The mark: Remembered in src/checks/queue.ts has a new base field. Both places that set a mark fill it in from the candidate's base: red alone, and red on its own merge or on top of its candidate.
• The check: enqueue is now async. It reads the base branch tip with resolveOid, but only for a pull that has a mark, so the common path does no git work.
• Same head, same base: a mark that still matches keeps the pull out as before, gated alone after the fresh pulls.
• Different base: a mark whose base differs is dropped, and the pull rides in a candidate with the others.
• Unreadable tip: if the tip can't be read, the mark is kept.

Tests

• Two new tests in test/merge-queue-clash.test.ts: red alone, then main moves, then enqueue gates it fresh in one candidate with the next pull. And red alone with main unmoved, which is still re-checked alone after the fresh pull.
• Three existing tests assumed a mark survives a landing, which is the behaviour this issue removes. I changed their setup, not their intent:

- The two clash re-check tests now re-mark B on the current base before the re-check (markedNow). - The "red pull stays out" test in test/merge-queue.test.ts now expects the re-gate to ride fresh with c, and the red-batch rate there is "2 of 4" instead of "1 of 3".

Not done: the "red" land decision in src/crew/autonomy.ts still holds a pull out until its head changes, apart from the 30-minute re-gate. That is the ledger, not the in-memory mark this issue names, so I left it alone. If #5666's 36 hours also came through that path, it needs its own change.