Key the client Minecraft cache on the latest loader build

[rubensworks]

Problem

mc-runtime-test caches ~/.minecraft under Linux-<mc>-<loader>-hmc, a key without the loader build, and skips the loader install when the cached vanilla json exists. actions/cache never re-saves on a hit, so CI keeps running whichever NeoForge build was current when that cache was first created, until someone deletes the caches by hand.

Fix

• .github/scripts/resolve-loader-version.sh resolves the latest loader build for a Minecraft version from the same sources HeadlessMC uses (Prism meta index for NeoForge and Forge, Fabric meta for Fabric). It fails the job if it cannot resolve, since HeadlessMC would fail on the same index anyway and a silent fallback would reintroduce the bug.
• The workflow caches ~/.minecraft itself, keyed on hmc-v1-<os>-<mc>-<loader>-<loader build>, and passes cache-mc: false to mc-runtime-test. A new loader release now invalidates the cache automatically. No restore-keys on purpose: a partial hit would still skip the loader install. Bump the v1 suffix to force a reset instead of deleting caches in the UI.
• The resolved build is written to the job summary, so each client job shows which loader it ran.
• mc-server-test gets cache-mc: false as well. Its cache entries were 234 bytes and the action reinstalls the loader on every run regardless (see Installing NeoForge Server 1.21.1-21.1.250 in cache-hit server jobs), so the server side was never stale and its cache and copy step were dead weight.

Notes

• The failures in the last two days of runs were game-test failures on server jobs, not stale-loader failures. The stale path is structural on the client side, confirmed by cache-hit client jobs that log no Installing NeoForge line.
• Cold client install costs 30 to 80 seconds per job; NeoForge ships several builds a week per line, so expect that roughly that often per ref. Three modpacks share a key, so two of them will log a harmless "cache already exists" warning on save.
• The old *-hmc cache entries stop being touched and expire after 7 days.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CyN8GNANjyR3ZMmqjeRQRq

---

Generated by Claude Code

[rubensworks]

CI status on 469f0f2:

Cache change verified. Client NeoForge jobs resolved the loader build, missed the new hmc-v1-Linux-<mc>-neoforge-<build> key, logged Installing NeoForge <mc>, and saved under the versioned key. Sibling modpack jobs that hit the key restored it. The three jobs that lost the save race logged "Unable to reserve cache", which is harmless.

One red job, not caused by this PR: Build (server, cyclops-all-deps, 26.1.2, neoforge) failed on the push run with evilcraft:gametestsbloodinfuser_testbloodinfuseremptyfluidcontainercreativeblooddrop (expected tank contents 10000, was 0 on tick 202), with the server logging "Can't keep up" throughout. The job installed the same NeoForge 26.1.2.109 as before this change, and the only steps this PR skips in mc-server-test are its 234-byte cache restore and the server copy step. The same job failed on #76, whose diff only touches the 26.2 pom, and passed on the push run of that same commit, so this is a timing-flaky game test rather than something this PR introduced. Re-ran the failed job once; the pull_request run of this commit is still in progress and serves as a second data point.

---

Generated by Claude Code