feat: Repo-controlled Go version via .go-version

[xdu31]

Problem

The Go version is specified independently in 5 places with no local enforcement:

• .settings.yaml (languages.go: '1.26.1') — CI workflows
• go.mod (go 1.26.1) — module minimum
• Makefile (go env GOVERSION) — local build uses whatever is installed
• validators/deployment/Dockerfile — hardcoded golang:1.26.1-bookworm
• validators/performance/Dockerfile — hardcoded golang:1.26.1-bookworm
• validators/conformance/Dockerfile — hardcoded golang:1.26.1-bookworm

A developer with the wrong Go version installed will silently build with it. Bumping Go requires editing 5+ files.
There is no local enforcement.

Proposal

Add a .go-version file as the single source of truth, following the same pattern used by
coredns/coredns@5556180. .go-version is a plain text
file (no yq dependency) and is natively supported by actions/setup-go via go-version-file.

Changes

1. Add .go-version containing 1.26.1
2. Makefile — read from .go-version and export GOTOOLCHAIN to enforce locally:
   GO_VERSION ?= $(shell cat .go-version)
   export GOTOOLCHAIN = go$(GO_VERSION)
3. CI workflows — replace go-version: ${{ steps.versions.outputs.go }} with go-version-file: .go-version
   (eliminates the load-versions dependency for Go)
4. Dockerfiles — use build arg fed from .go-version:
   ARG GO_VERSION=1.26.1
   FROM golang:${GO_VERSION}-bookworm AS builder
5. .settings.yaml — remove languages.go (no longer the source of truth for Go)
6. load-versions action — read Go version from .go-version instead of .settings.yaml

Bump Go version = edit one file (.go-version), everything follows.

References

• CoreDNS implementation: coredns/coredns@5556180
• actions/setup-go go-version-file support:
  https://github.com/actions/setup-go#getting-go-version-from-the-go-version-file

[mchmarny]

We already have this in .settings.yaml

# Language Versions
languages:
  go: '1.26.1'

I do think for purposes of validators we need to keep these independent as much as possible so even at the cost of having have to manager this in each one of the 3 validator images that would still be the right trade off IMO just to limit the blast radius of the inevitable evolution differences between each one of them.

[xdu31]

We already have this in .settings.yaml

Agreed — .settings.yaml has the version, but nothing enforces it locally. The Makefile reads go env GOVERSION (whatever's installed), so a developer on the wrong Go version builds silently. .go-version + GOTOOLCHAIN closes that gap. It can coexist with .settings.yaml — .go-version for Go enforcement specifically, .settings.yaml for everything else. This is the same approach used by https://github.com/kubernetes/kubernetes/blob/master/.go-version and https://github.com/coredns/coredns/blob/master/.go-version.

I do think for purposes of validators we need to keep these independent

Go breaking changes only happen at minor version boundaries (e.g., 1.26 -> 1.27); patch versions are pure bug fixes and CVE fixes. Unless we need different Go minor versions across validator images — which would imply a low-level runtime incompatibility — a unified version fits. A single .go-version ensures consistent security posture and reproducible builds across the main binary and all validator images, with one file to bump for CVE updates.