ci: goreleaser and both Jules daily workflows pin checkout/setup-go three majors behind the repo (v4 vs v7) #394

Summary

Four action pins in three workflows lag three majors behind the version every other workflow in this repo uses. The repo standard is @v7 for both actions; the lagging sites are all in workflows that run rarely (tag pushes, daily Jules schedules), so nothing surfaces the drift in normal PR CI.

Evidence (verified on main 6c027ad1, 2026-10-20)

Repo-wide pin census (grep -rhn "uses:" .github/workflows/*.yml):

• actions/checkout@v7 — 17 sites; actions/checkout@v4 — 3 sites:
  • .github/workflows/goreleaser.yml:61
  • .github/workflows/jules-daily-codebase-ideation.yml:37
  • .github/workflows/jules-daily-flake-sync.yml:37
• actions/setup-go@v7 — 7 sites; actions/setup-go@v4 — 1 site:
  • .github/workflows/goreleaser.yml:65 (same file as the checkout lag, adjacent step)

Everything else is current or deliberately SHA-pinned (DeterminateSystems actions, jules-action@v1.0.0).

Why it matters

• v4-era actions run on the older Node runtime GitHub has been deprecating; the tag-triggered goreleaser workflow is exactly the one that must not discover a forced runtime migration on release day (it already has an unrelated setup failure tracked in CI: goreleaser workflow fails in setup on the next tag push — go-version-file points at go.work, deleted in Feb 2024 #344 — this is a separate, simpler pin fix, not a duplicate).
• Mixed majors make future Dependabot/Renovate bumps and audits noisier: a reader cannot tell whether a v4 pin is deliberate.

Acceptance criteria

• The three actions/checkout@v4 sites and the one actions/setup-go@v4 site are bumped to @v7, matching the rest of the repo.
• No other pins change; workflow triggers, permissions, and step inputs are untouched.
• YAML parses for all three files and the PR's checks pass.