feat(setup-go): release-cache — a release-scoped Go cache for goreleaser jobs

[blairham]

Why

Release jobs rebuild the whole cross-compile matrix nearly cold every time. actions/setup-go's built-in cache can't help them: (1) its key is exact-match on go.sum — no restore-keys — so any dependency bump is a fully cold build; (2) a cache key's snapshot is immutable and saved by whichever job first claims it, usually a CI test job whose GOCACHE contains only host-platform test builds — useless for the other five GOOS/GOARCH targets. k4a's last release spent 457s of its 9 minutes inside 'Run GoReleaser' for exactly this reason.

What

Opt-in release-cache: true on the setup-go composite:

• Disables the built-in cache and adds an explicit actions/cache over ~/go/pkg/mod + ~/.cache/go-build.
• Key go-release-<os>-<hash(go.mod, go.sum)> — namespaced away from CI's cache, toolchain bumps roll it.
• restore-keys prefix fallback — a dependency bump restores the previous release's cache and compiles incrementally instead of cold.
• The post step saves at job end, after goreleaser — so the snapshot carries the build cache for every cross-compiled target, and the next release restores a full-matrix warm cache.

Default false: no behavior change for any existing caller.

Rollout

Merge this first, then flip release-cache: true in the release.yml of the goreleaser repos (k4a, k5s, cloudctl, cwlogs, pp-tui) — k4a PR follows as the first caller. First release per repo populates the cache; the second one gets the speedup (expect k4a well under half its current 9min).

[blairham]

Superseded by #58, which generalizes this: per-job cache scopes mean a goreleaser job (job id release) automatically gets its own flag-set-specific cache with restore-keys, saved at job end after goreleaser — everything release-cache: true provided, for every job shape, with zero caller opt-in. Same-file conflict resolved by withdrawing this one.