Separate the Go minimum from the release build toolchain

docs/release.md

@@ -12,8 +12,36 @@ succeeded. CI and consumer installation are not completion checks.
 
 ## Prepare a candidate
 
-Use a local Go 1.25 toolchain and a clean clone. Start on `main`, choose an
-unused stable `vMAJOR.MINOR.PATCH` version, and add
+Use a clean clone on `main`. The chosen build toolchain is Go 1.26.8. Make that
+local installation the active `go` command for preparation, building the release
+executable, and candidate validation:
+
+```sh
+export GOTOOLCHAIN=local
+go version
+```
+
+Record the reported version with the validation results. The
+[Go support policy](policy/release.md#go-minimum-and-release-toolchain) owns
+series selection, consumer minima, patch exceptions, and validation scope.
+The maintained [source-delivery image](../examples/woodpecker/releasekit-source-delivery.yml)
+and [consumer template image](../examples/woodpecker/tag-delivery.yml) follow the
+chosen build toolchain; update them together when that selection changes.
+
+The current consumer minimum is declared in [go.mod](../go.mod). When preparing
+a release that raises it to Go 1.26, the normal declaration is:
+
+```sh
+go mod edit -go=1.26.0
+```
+
+Retain any higher patch minimum required by dependencies or a specific fix.
+Make module changes before committing the candidate. A release preserving the
+existing minimum keeps its current declaration. Minimum increases must fit the
+[compatibility policy](policy/release.md#versioning-and-compatibility); before
+v1.0.0, an increase belongs in a minor release.
+
+Choose an unused stable `vMAJOR.MINOR.PATCH` version, and add
 `docs/releases/<version>.md` with a first heading containing `ReleaseKit` and
 the exact version. Summarize the change and any compatibility or upgrade impact.
 End the note with the three license links at the immutable source tag: