Merge queue and automerge of forward-merge PRs (Phase 3 of MDBF-895)

Context

In Phase 2, clean forward-merges are auto-created PRs that humans merge. Phase 3 removes the human click for the safe case: a forward-merge PR that is clean and CI-green merges automatically. Conflicts and CI failures always go to humans. PLC goal: new Buildbot always green / branch protection / automerge.

The tool should run from early in the release cycle, so merge overhead is absorbed continuously in small increments instead of accumulating into the end-of-cycle merge pressure we have today.

Entry criteria: Phase 2 running; merge PRs routinely merged without manual fixes; branch protection enforced on all chain branches (MDBF-523).

Mechanism

Batching model

• Each run batches all pending commits per edge into one forward-merge, advancing up to the first breaking change.
• At a breaking change, the run stops for that edge, and the likely author is contacted to triage: if the fault is elsewhere, they reassign; otherwise, they merge the updated changes themselves.
• Once the blocking change is resolved, the tool resumes with subsequent changes in the same pattern.

Merge queue (hard requirement — not plain GitHub auto-merge)

• Plain GitHub auto-merge requires a PR to be fully synced with its base. With several merge PRs targeting the same base, the first one to land makes the others "outdated" mid-CI: their auto-merge silently de-qualifies, CI time is wasted, and someone has to notice the failure. Therefore, the implementation must provide real queue semantics:
• serialise merges racing to the same target branch;
• guarantee CI runs on the actual post-merge state before the push lands;
• automatically update/rebase and retest a queued merge PR that loses a race;
• never fail silently: any entry ejected from the queue (race loss, CI failure) triggers a notification.

Other

• Enable automerge only for the auto-created forward-merge PRs (not contributor PRs).
• Notification on completion (Monty's requirement) and on any automerge failure (falls back to Phase 1/2 behaviour: human resolves).
• Kill switch: a config flag per edge to disable automerge and fall back to Phase 2 behaviour.

Open questions/risks

• GitHub merge queue limitations with external CI (Buildbot status reporting) — see "GitHub merge queue limitations" link on MDBF-895; evaluate native queue vs Mergify vs Aviator. Own scripting of gh pr merge --auto is disqualified unless it implements the queue semantics above (see comment from Jimmy Hú, 2026-06-12).
• Author triage flow: how is the "likely author" determined and contacted (Phase 1 approximation + Slack), and how is reassignment tracked?
• Interaction with humans pushing directly to protected branches while a queue entry is in flight.
• Per-branch CI duration vs queue throughput at daily cadence (likely a non-issue).

Test cases

• Clean merge PR + green CI: merges with no human action; completion notification sent.
• Batch of N commits with a breaking change at commit k: commits before k merge; chain stops at k; author notified; after resolution, the tool resumes with the remainder.
• Two merge PRs racing to one target: serialised; loser rebased and retested automatically; no silent de-qualification.
• CI failure in queue: PR ejected, notification, no push to protected branch.
• Kill switch disables automerge for one edge only.