Hash-verify the Go toolchain in the release workflow (closes #105)

The release workflow installed Go via actions/setup-go, which pins the
action but not the toolchain tarball it downloads at runtime -- the
compiler that produces the published binaries was the last external
input in the release path verified against nothing in the repo, against
REPO_POLICIES.md's hash-pin rule.

New script/install-go, modelled on script/install-goreleaser, downloads
the exact go.dev archive for go.mod's `go` directive and refuses it
unless its sha256 matches a value committed in the script. release.yml
calls it instead of setup-go and sets GOTOOLCHAIN=local so that exact
compiler builds the release. The version is not duplicated: go.mod owns
it and install-go fails when its committed GO_VERSION disagrees, so
bumping Go edits go.mod, the checksum, and the Dockerfile golang digest
together.

Model: opus-4-8

TODO.md

@@ -25,6 +25,16 @@ release" is exactly the contradiction
 
 # Completed Steps
 
+- 2026-09-21: Hash-verified the Go toolchain in the release workflow
+  ([issue #105](https://git.eeqj.de/sneak/vaultik/issues/105)). New
+  `script/install-go` downloads the exact `go.dev` archive for `go.mod`'s
+  `go` directive and refuses it unless its sha256 matches a value
+  committed in the script; `.gitea/workflows/release.yml` calls it
+  instead of `actions/setup-go`, which verified the downloaded toolchain
+  against nothing in the repo. `GOTOOLCHAIN: local` on the release step
+  keeps that exact compiler from auto-switching. Bumping Go now touches
+  `go.mod`, the checksum, and the `Dockerfile` `golang` digest together.
+
 - 2026-08-10: Moved every lint run into its own container, as a build
   step ([issue #113](https://git.eeqj.de/sneak/vaultik/issues/113)).
   New root `Dockerfile.lint`, built by `script/lint`, runs