Verification runs ~25 min of local gates on a head whose CI test job already failed, holding the single CPU admission slot #4531

Problem

Verification keeps running every local gate (install, typecheck, frontend-typecheck, lint, build, server-bundle: about 25 minutes) on a head whose CI test job has already failed. Only after all of that does it fail test with "The CI test job already failed on this head". Heavy gates hold the machine-wide CPU admission slot one at a time (src/lib/cloister/quality-gate-admission.ts, PAN-4311). A verification run that is certain to fail therefore blocks every other issue's verification, and the agent's own isolation test runs, which enter the same queue.

Observed 2026-10-04 on PAN-4259 (times UTC):

• ~04:10: a verification worker starts on head 2665f45c.
• 04:14:56: the CI test job fails on 2665f45c (test-shard (4/4), .overdeck/verification/2026-10-04T04-14-56-585Z-2665f45c.json).
• 04:37: the worker still holds the admission slot running lint for that head (~/.overdeck/verification-workers/admission/owner.json: {"issueId":"PAN-4259","gateName":"lint"}). Seven waiters are queued behind it, including the PAN-4259 agent's own vitest run tests/unit/lib/access-tokens.test.ts isolation run, which it needs in order to fix the CI failure.

Root cause

src/lib/cloister/verification-runner.ts ~lines 578-590:

const ciTestRed = testsMode === 'ci'
  && !localGateResults.some((r) => !r.passed && r.required !== false)
  && readLatestCiTestResult(workspacePath, headShort) === 'failed';

The CI verdict for the head is read only after every local gate has run. Nothing checks it before a gate starts, or between gates.

Fix

1. In ci tests mode, read readLatestCiTestResult(workspacePath, headShort) before the first local gate and again before each later gate requests CPU admission. If it is failed, stop at once: record the same failed test gate result and output as today, mark the remaining local gates as not run, and release the admission slot.
2. Keep today's message and attempt accounting: a re-request on the same head still counts against the attempt budget (PAN-3965 behavior).
3. Use the head actually being verified. Coordinate with PAN-4527, which fixes the launch-time headShort mismatch, and do not reintroduce it.

Acceptance criteria

• Given CI recorded failed for the verified head before verification starts, the runner runs no local gate, never requests CPU admission, and returns failed at test with the existing message (runner unit test).
• Given CI flips to failed while a local gate is running, the next gate does not request admission, and the run ends failed at test (unit test with fake timers for any polling).
• Given CI is passed or unknown, behavior is unchanged (existing tests stay green).
• docs/PIPELINE-GATES.md (verification gate, ci tests mode) states that a known-red CI head short-circuits local gates.

Routing

This is review/verification machinery (TENET-10). Route it through a supervised pan handoff, together with or after PAN-4527.