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: media-sdk 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 227 MB, created 2026-08-06, 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.

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 frozen 227 MB media-sdk entry this PR stops writing to should be deleted; nothing will read it again.