CI perf: coverage and e2e-build wait ~1.4 min for clippy on every run; clippy failed 0 of 256 PR runs in 7 days #1681

Problem

coverage and e2e-build (needs: clippy) can't start until clippy finishes. Both critical-path chains, coverage and e2e-build → e2e (Gradle), therefore start about 1.4 min late on every CI run.

The gate is meant to save money when clippy fails. It didn't fire in the last 7 days: across 256 pull_request CI runs since 10-16, 6 failed, and clippy failed in none of them. coverage failed in all 6. In the merge queue, merge-queue-fail-fast.yml already cancels the run on the first failed job, and windows-compile-check already skips the gate for that reason (#1385).

Proposed fix

• Add a tiny preflight job (checkout plus the two reuse checks, ci-reuse-merge-group.py and ci-reuse-pr-head.py) that owns the reuse / pr_unchanged outputs. Change every needs.clippy.outputs.* to needs.preflight.outputs.*.
• coverage and e2e-build get needs: preflight. The other needs: clippy jobs get needs: [preflight, clippy], so nothing else changes. Add preflight to ci-ok's needs. clippy keeps its name and stays required.
• Every test still runs where it runs today. Only the start order changes.

Expected saving

About 1.2–1.4 min off every merge_group and PR ci-ok. That is ~1.4 min, minus a ~10–20 s runner start for preflight, on a ~7.9 min critical path, so about 16%. On a red clippy, the cost is at most one coverage + e2e-build (+ fan-out) on PRs, about 30 Linux job-min per incident. That's 0 incidents in 7 days.

ROI: (1.3 critical-path + 1.3 PR-latency) × 0.8 ÷ S(1) ≈ 2.1

Blocker

Not implemented this run: open PR #1639 (ci-janitor, agent:needs-human) also changes .github/workflows/ci.yml, and the implementer skips files another open PR changes. #1639's uv pin is already on main (ci.yml:1468-1472, pipenv-compatibility.yml:109), so #1639 is a no-op. Once it is closed, the next implementer run can take this issue.

Generated by Claude Code