The merge queue survives a rollout: gates in flight resume on the new pod instead of starting over #6611

Seen 2026-10-26 21:24Z. 0.7.270 rolled, and the new pod re-formed the queue from nothing: two gates of 14 pulls restarted at 21:24, and the old pod's ~10 gate-minutes were lost. The queue and its "told red on this head" marks live only in memory. The steward releases about hourly, so each release costs about one gate round of landing. Landed per hour dropped from 34 to 4 across the roll.

Done when:

1. Gate candidates are recorded in the database: pulls, base sha, the speculative tree sha, the check run id, and started_at. Red marks are recorded too, keyed by (pull, head, base).
2. On boot the queue adopts gates still running on the check lane. If the run is gone, it re-gates the same candidate on the same base, without re-planning.
3. A test: kill the queue mid-gate, restart it, and the same candidate lands with no second gate run.

Part of #6001 (pipeline: 10x landed per hour). Owner 2026-10-26: "prioritize development pipeline optimizations".

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Also (steward, 22:50Z): a hold must take a pull out of the line, not just block its admission.

landIfGreen refuses a held pull (autonomy.ts:1827), but a pull already waiting stays in the in-memory line until it reaches a gate. Holding 14 MCP-tool pulls (#6612's budget clash) left the line at 60 waiting for 3+ minutes. Every new batch can still pick two of them and go red.

Done when: setting a hold (or a close, a new head, or a lost approval) drops the pull from the line within one sweep, and the tick line's waiting count reflects it. Test: enqueue 3 pulls, hold the middle one, and the next batch has 2.