CI pins go-version 1.22 — two EOL generations below the published floor

[yakimoto]

Found while fixing #59. Not urgent and not currently breaking anything — filed so it is not lost.

What

Both Go workflows pin an explicit toolchain:

file	line	pin
.github/workflows/test-go.yml	34	go-version: "1.22"
.github/workflows/release-go.yml	25	go-version: "1.22"

Go 1.22 reached end-of-life on 2025-02-11. After #59 lands, sdk-go/go.mod declares go 1.25.0.

Why it is not currently a bug

GOTOOLCHAIN=auto (the default) only ever switches UP, never down. So setup-go installs 1.22, Go reads the go directive in go.mod, and silently upgrades itself to satisfy it. That is precisely why CI stayed green while the module was on 1.24: measured on this repo, setup-go installed 1.22.12 and the toolchain switched up on its own. The workflow pin has never been the operative version.

Why it is still worth fixing

1. It is a trap under GOTOOLCHAIN=off. Any consumer or CI lane that disables auto-toolchain gets a hard build failure, and the workflow reads as though 1.22 were supported.
2. It misreports what we test on. Someone reading these files reasonably concludes the SDK is verified against 1.22. It is not — it is verified against whatever the directive forces.
3. It wastes a download every run — fetch 1.22, then immediately fetch the real toolchain.

Fix

Point both at the module rather than a literal, so they cannot drift from the floor again:

- uses: actions/setup-go@v5
  with:
    go-version-file: sdk-go/go.mod

That is the same mechanism wave-dispatch uses, and it makes go.mod the single source of truth — matching the fix in #59, which moved the version into one named constant (GO_VERSION in codegen/render_go.py) for the same reason.

Deliberately kept out of #59 to keep that PR single-purpose and green while it is blocked on review.