perf(ci): investigate yarn install --check-files (caches are cache-independent, not a hit-rate win) — follow-up to #363

[scottschreckengaust]

Parent: #363 (build-performance umbrella). needs maintainer approved before implementation (ADR-003).

⚠️ Corrected 2026-07-29 after measured re-review of PR #364 (@theagenticguy). This issue was originally filed as "fix merge_group cache misses to save install time." Measurement disproved that premise — see below. The issue is retained but re-scoped to the actual question (do these caches earn their restore cost), and it is no longer the lead lever.

Corrected finding

The merge_group cache misses (node_modules=miss, venv=miss, jest=miss) are largely structural, not a misconfiguration: per GitHub's cache docs, a cache created by a pull_request run is scoped to the merge ref (refs/pull/.../merge) and can only be restored by re-runs of that PR — merge-queue refs cannot read PR-branch caches.

More importantly, fixing hit-rate saves ~zero. Same yarn.lock hash, miss run 30412723686 vs hit run 30419878840:

	miss	hit
Cache * restore steps	1s	9s
yarn install --check-files	48.35s	55.09s
Install dependencies step	56s	60s

The cache-hit path is net slower. Cause: mise.toml [tasks.install] runs yarn install --check-files, which re-verifies every file and defeats a restored node_modules. uv sync on the miss run reported Prepared 127 packages in 1.77s, Installed in 121ms, so a venv cache costing ~3s to restore cannot pay for itself either.

Re-scoped question (if pursued at all)

Install cost is cache-independent here. The real question is whether yarn install --check-files is necessary, and whether these caches earn their restore cost at all:

• Investigate dropping/replacing --check-files (measure correctness risk vs the ~48–55s it costs regardless of cache state).
• If caches don't earn their restore cost on either event, consider removing the cache steps rather than "fixing" them.

Priority

Not the lead lever. The dominant addressable overhead is the Free Disk Space step (see the new issue and the re-ranked sequencing on #363). Sequence this after Free-Disk-Space, runner-bump (#677), and path-filters (#678). See docs/design/CI_BUILD_PERFORMANCE.md (corrected in PR #364).

Refs #363