fix(ci): prime module cache before monorel runs GOPROXY=off tidy

[theogravity]

Summary

Follow-up to #77. setup-go alone wasn't enough: monorel v0.12+ runs go mod tidy per sub-module with GOPROXY=off, so it can only resolve modules already in the local module cache. On a fresh runner with no cache hit (any time a sub-module's go.sum changes and the cache key invalidates), tidy fails:

go.loglayer.dev/transports/cli/v2 imports
    github.com/mattn/go-isatty: module lookup disabled by GOPROXY=off

Repro: https://github.com/loglayer/loglayer-go/actions/runs/25272377315/job/74096786410

Fix

Two changes per workflow:

1. setup-go now has cache: true and cache-dependency-path: '**/go.sum' (mirrors ci.yml). On warm cache hits (typical case), modules are pre-extracted into the runner's GOMODCACHE.
2. New "Prime module cache for monorel tidy" step walks every go.mod in the repo and runs go mod download per module. This populates the cache from the network on cache-miss runs (e.g., the first run after a sub-module's go.sum changes), so monorel's GOPROXY=off tidy always finds what it needs.

Applied to both release-pr.yml and release.yml.

Upstream

The cleaner fix lives in monorel itself: the action should either prime the cache before tidy, or use the runner's default GOPROXY (since go.sum hashes provide the same determinism guarantee GOPROXY=off aims for). Filed at disaresta-org/monorel#54. Once monorel ships the upstream fix, this priming step can be reverted.

Test plan

• After merge, the next push-to-main triggers release-pr and the workflow completes successfully.
• At the next release-pr merge, the release workflow runs the publish pipeline cleanly.

🤖 Generated with Claude Code