Should `test.yml` and `lint.yml` use the latest stable Go instead of the go.mod version?

Nobody has claimed this yet.

Today `test.yml` and `lint.yml` use `go-version-file: go.mod` with `check-latest: true`, so CI proves the module at its declared minimum Go version (latest patch). The alternative is `go-version: stable`, which catches breakage on the newest release first.

Considerations:
- `compatibility.yml` already runs `stable` × `go.mod` nightly, so both versions are covered either way; the question is which one gates merges.
- For libraries (gomponents, gai), the declared minimum is a promise to users, so failing CI when it breaks is valuable.
- For apps, the deployed toolchain is whatever the Dockerfile uses, so `stable` in CI may be the more honest signal.
- A single answer for all callers keeps the workflows input-free; a per-repo choice would need an input.

Raised in review of #3.

Start by reading test.yml and lint.yml to compare their go-version-file and check-latest settings, then inspect compatibility.yml and go.mod to understand the existing version coverage. Check the Dockerfile context for deployed toolchains. Done requires a decided policy for merge-gating versions and an agreed workflow change, including whether all callers share it or need a per-repository choice.

Written by the indexing model from the issue text.