ci: fix the Go build cache never being hit

[u9g]

The Test job compiles the module from scratch on every run, because neither of the two caches configured here has ever produced a hit.

The actions/cache step used a constant key. key: server-sdk-go never changes, and actions/cache does not re-save on a hit, so the entry stayed frozen at whatever it held when first written. The cache API reports it as 741 MB, created 2025-11-14, still being restored today — and because every run reads it, its last-accessed time keeps refreshing, so it never ages out either. Nothing in it could match: it cached all of ~/.cache, whose go-build entries are keyed by compiler build ID, so a newer toolchain misses every one. It cost time on every run and left a GOCACHE full of dead entries that setup-go then re-uploaded.

setup-go's built-in cache cannot close the gap. Its key is setup-go-{os}-{arch}-{linuxver}go-{version}-{go.sum hash}, and it calls restoreCache with no restore keys — a match is exact or nothing, and upstream has declined to add prefix fallback (actions/setup-go#404). So any dependency bump rebuilds everything rather than just the part that changed, and a Go point release rotates the key out from under every open PR at once.

The repo is over its cache budget. It currently holds 11.78 GB against a 10 GB limit, so entries are being evicted continuously. Two refs/pull/N/merge setup-go entries are ~1.25 GB each, in a scope no other run can read. (CodeQL separately writes ~750 MB per run; not addressed here.)

What this changes

• Drops the dead actions/cache step.
• Sets cache: false on setup-go and restores via actions/cache/restore, keyed on the go.sum hash with a prefix fallback, so a dependency change reuses the entries that are still valid.
• Suffixes the key with run_id so it never matches on write. A push therefore always stores a fresh entry, rather than one pinned to the go.sum that first created it.
• Limits saving to pushes. Pull requests read main's entry and write nothing, which keeps roughly a gigabyte per PR run out of the repo's 10 GB budget.

Narrowing the paths to ~/.cache/go-build and ~/go/pkg/mod drops ~/go/bin. Binaries installed there are re-go installed on every run regardless, and the build cache covers most of that cost.

The save step reuses the restore step's cache-primary-key output rather than re-evaluating hashFiles, because the Replace mutexes step rewrites go.mod/go.sum partway through the job. The key therefore reflects the committed go.sum, not the mutated one.

Follow-up, not in this PR

The stale entries need clearing to get back under budget, including the 741 MB server-sdk-go one this PR stops writing to.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.