feat(ci): the workflow runner drains through a bounded pool, not serially #5510

Scorecard move #2 of the greenlit 1–6 block

The CI queue was strictly serial — one slow run stalled every other repo's CI behind it, the loudest "toy" tell for a second concurrent user.

• The tick now fills up to WORKFLOW_CONCURRENCY slots (default 3, clamped 1..16 — one box, runner lives inside the app container; this is "stop being serial", not "be a build farm").
• Each slot is the existing drainOneRun() — its queued→running conditional UPDATE was always multi-worker-safe; there was simply never a second caller. No double-execution is possible.
• Empty-queue latch: refills stop once a claim comes back empty and resume only when a slot that did work completes — an idle pool can't spin claim roundtrips against Neon while a long run is in flight.
• Per-run mkdtemp workspaces were verified isolated before parallelizing.
• The source-pinned invariants from workflow-run-abandonment.test.ts (reap before drain, one-shot restart sweep, terminal-status guarantees) are preserved and still pass.

Tests: new workflow-runner-concurrency.test.ts (resolver clamping + pool source pins), 16/16 across both runner test files, typecheck clean.

🤖 Generated with Claude Code