fix(ci): an unwritable checkout dir must not take CI down platform-wide #5598

A second commit landed on this branch — a separate bug found while diagnosing the incident above.

6852c73 — the REST API 404s on a repo you capitalised differently

/api/v2/repos/ccantynz/gluecron.com/... returned 404 while /ccantynz/gluecron.com in a browser rendered the repo and /api/v2/repos/ccantynz/**G**luecron.com/... worked. resolveRepo in api-v2.ts was the last resolver still using exact equality; loadRepoByPath has matched case-insensitively for months, and the web UI and MCP tools already go through it.

Names are stored lowercase going forward (2c6cd93), but rows created before that keep their capitals — Gluecron.com, Vapron — so exact matching is wrong for data that exists today, not merely for careless clients.

The failure mode is what makes this more than a casing nit: a 404 that depends on how a client capitalised a URL is indistinguishable from "this repo does not exist", and a polling client reads it as silence. That is how it was found — a CI monitor in this session watched that exact URL and reported nothing while the run it was watching finished and failed. Twice.

Named in the code, deliberately not fixed here

This resolves user-owned repos only, so an organisation's repository is unreachable through the entire v2 API. Not a one-line change: 44 call sites use resolved.owner for authorization (user.id !== resolved.owner.id), and an org id in that slot would deny every request rather than allow the wrong one.

A ratchet on the wider class

127 call sites still match repository names with eq(repositories.name, x). The sweep to route them through loadRepoByPath has been pending since 2026-08-05, and a sweep that size isn't something to do blind.

The ratchet can't fix them, but it stops the class growing — and it fails when the count drops too, so the baseline gets tightened as the sweep progresses. A ratchet nobody tightens is just a number that used to be true.

It earned its keep immediately: it caught that my own baseline of 132, taken from a grep, was wrong.

Correction to this PR's description. It said PR #5597 merging through a checkout_failed run was "the merge gate working as designed — checkout_failed is an infrastructure conclusion, and our failures never block your merge."

That was wrong, and the real answer is worse.

decideCiGate already blocks on infrastructure conclusions:

if (infra.length > 0) {
  return { name: "CI", passed: false,
    details: `CI did not complete — ${infra.join(", ")}. Re-run the workflow …` };
}

So the gate never intended to let that through. The reason #5597 merged is the bug found afterwards and fixed in #5599: lookupRepo was exact-match on the repository name, a caller passing gluecron.com against a repo stored as Gluecron.com got null, and null was rendered as a passing CI check. The gate wasn't being lenient about infra failures — it wasn't running at all.

The open question I raised here therefore doesn't exist as posed. What replaced it is narrower and now answered by #5599: a check that could not be performed must never score as one that passed.

Verified end-to-end in production after #5599 deployed — the same lowercase call against #5600 while its CI was running:

{ "merged": false, "reason": "CI: CI still running: CI — merge when green" }

Separately, docs/CI-ATTRIBUTION-GUARANTEE.md §2 is headed "Our failure never blocks your merge", which the code above contradicts. The code is right and the doc overstates the promise; fixing the doc rather than the code.