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

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

docs/design/CI_BUILD_PERFORMANCE.md と mise.toml の [tasks.install] 定義から始めます。参照されている run を使って miss と hit の比較を再現し、そのうえで yarn install --check-files が必要かどうか、また venv と node_modules のキャッシュが復元コストに見合うかどうかを評価します。--check-files を置き換えるかどうか、およびキャッシュのステップを維持するか削除するかについて、測定に基づく判断ができれば完了です。

索引モデルが issue の本文から書いたものです。