The merge queue says why a gate went red, and never bisects a merge conflict or an install failure (8-pull batch red in 6 s, then bisected) #5276

Probe, 2026-10-22 09:30Z, on 0.7.248 (which already has #4999).

09:30:23 [queue] gating 8 pulls … #5088,#5089,#5090,#5091,#5094,#5100,#5102,#5120 waiting=63
09:30:29 [queue] gated 8 pulls: red … took=6s
09:30:29 [queue] gating 3 pulls … / gating 6 pulls …   (bisecting)

• The failure: a batch went red in 6 s, far too fast for any test, so a step before the tests failed: most likely the batch merge itself (two pulls conflicting), or setup or install (see #5093).
• What the queue did: it treats that exactly like a red test run and bisects, spending about 8 minutes per round while 63 wait. Only 1 pull landed in 20 minutes, and 0 in the 20 before that.
• What the log says: nothing about why a gate went red.

Done when:

• Every gated … red line carries its reason: merge-conflict (#a × #b), install, typecheck, tests: N failed, or timeout.
• A merge conflict inside a batch is not red. Drop the later pull of the conflicting pair from this batch, return it to its builder to bring up to date, and re-gate the rest at once. No bisection.
• An install or infrastructure failure is not red (#5093): retry once, then mark the gate infrastructure. Pulls never go red for it.
• Bisection only for test or typecheck reds.
• Test: a batch where #b conflicts with #a lands everything else in one gate, and #b goes back for update.

Parked by the crew: the check stayed red through 2 automatic tries (pull #5293 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

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