ci: repeated pushes to a PR don't reuse Go build objects #781

Problem. Repeated pushes to the same pull request get no incremental reuse of Go build objects. Every push recompiles the PR's changed packages from the cache it restored. Long-lived PRs that are pushed often pay that cost on every push, and PR CI is where people usually wait.

Why (measured by reading .github/actions/setup-env/action.yml).

• The Go build cache key is gobuild-v3-<os>-go<suffix>-<hash of go.mod/go.sum>, and actions/cache saves only when that key misses.
• A PR that doesn't change dependencies has the same key as main. It restores main's entry and never saves.
• Later pushes to the same PR also restore that entry and don't update it, so objects compiled on an earlier push are never kept.
• A PR that changes dependencies: with ci: save the large caches only from main #758, it also restores main's entry via restore-keys and redoes the dependency delta on every push.

Constraints.

• Repo cache budget: 10 GB. Above it, GitHub evicts least-recently-used entries, including main's warm ones, which makes every PR start cold.
• Why ci: save the large caches only from main #758: on 2026-10-07, one dependency-changing PR held 6.1 GiB of PR-scoped entries, and the repo sat at the cap. ci: save the large caches only from main #758 stops PRs saving for that reason.
• Existing cleanup: with ci: save the large caches only from main #758, pr-cache-cleanup.yml deletes a PR's caches when the PR closes.
• Size: a full Go build cache set is about 1.3 GiB for build objects alone, per suffix. CI has six Go suffixes.

What to find out.

• How much wall-clock a warm per-PR build cache saves on the second and later pushes of a typical PR, per job.
• Whether that fits the budget with several long-lived PRs open at once.

The .github/workflows/README.md sizing policy is the place the budget arithmetic lives.

Related: #535, #758. Part of #740.