P0: the merge queue records and names the tests that failed each gate (not just the count), with a gates API, so a red batch can be acted on #6739

P0 for the pipeline (steward, 2026-10-27 04:15Z): the merge queue must record which tests failed, not just how many.

Since about 01:30Z nearly every gate reads red (tests: 2 failed) or red (tests: 4 failed), and landing fell to 1–2 an hour with 60 green pulls waiting. Nobody can say which tests:

• the log line carries only the count (#6615);
• gates aren't run rows, so the run log has nothing;
• /data/checks/gate-* is just the working tree.

The steward tried and failed: README (fixed at aea248a), then the readPlan budget (scaled to a baseline, passes alone 3/3), then guessing. Every guess costs a gate round.

Done when:

1. Each finished gate stores its verdict: state, the counts, the failing test names (up to 20), the first error lines of each (up to 5), and the duration, in a gate_result table (or on check_gate), kept 7 days.
2. The queue log line names them: gated 8 pulls: red (2 failed: "a > b", "c > d").
3. GET /api/v1/repos/:o/:n/queue/gates?limit=20 returns recent gates with their pulls, verdicts and failing tests, so the steward, the flow alarm and a future board can read them.
4. The flake list from #6643 reads from this table: a test failing in two batches with no pull in common gets flagged automatically.
5. Tests: a fake gate with 2 failing tests stores both names; the log line contains them; the API returns them; the count matches.

Files: src/checks/queue.ts, src/checks/gate*.ts, src/core/migrations (new), src/http/api.ts, tests

Parked by the crew: the check failed ("no GET route answers 200 without a session phase unless the allowlist names it") and the decider saw no point in another try (pull #6740 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): filed under P0 Trust, which it names.