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

The release workflow installed Go with actions/setup-go, which pins the action but not the Go archive it downloads, so the compiler that builds the published binaries was verified against nothing in this repo.

New script/install-go, modelled on script/install-goreleaser, downloads the go.dev archive for the version in go.mod and refuses it unless its sha256 matches the value committed in the script. It fails if its version disagrees with go.mod, and on any OS or architecture other than the Linux release runners. GOTOOLCHAIN=local on the release step keeps the verified toolchain from switching itself.

Judgement call: release path only; script/bootstrap still uses the host Go.

model: claude-opus-4-8 (implementation, review); claude-fable-5-1 (merge)

.gitea/workflows/release.yml

@@ -20,33 +20,21 @@ jobs:
       # check.yml runs script/cibuild, which does all of its work inside
       # the digest-pinned Dockerfile images -- so without this step the
       # release either fails at the before-hook or, worse, ships binaries
-      # built by whatever unpinned Go the runner happens to carry.
-      # REPO_POLICIES.md requires every external reference to be pinned,
-      # and script/release already refuses a goreleaser that is not the
-      # pinned build; the compiler that actually produces the artifacts
-      # is the last thing that should be exempt from that.
+      # built by whatever Go the runner happens to carry.
       #
-      # go-version-file rather than a literal: go.mod's `go 1.26.1` is
-      # the single source of truth for the toolchain, the same way the
-      # Dockerfile FROM line is the single source of truth for the
-      # linter version that script/lint enforces. It is a three-component
-      # version, so setup-go resolves it exactly -- no silent drift onto
-      # a newer patch release.
-      #
-      # actions/setup-go v5.6.0, 2025-12-15. Pinned by commit sha, like
-      # the checkout above. v5.x is a node20 action, matching the node20
-      # actions/checkout v4 already in use here; the v6/v7 line requires
-      # a node24 runner, which this Gitea runner has never been asked
-      # for and cannot be assumed to provide.
+      # actions/setup-go would pin the action by commit sha, but the Go
+      # tarball it downloads at runtime is verified against no value in
+      # this repo, and the action exposes no checksum input.
+      # REPO_POLICIES.md requires every external reference to be pinned
+      # by hash with no exceptions, and this is the compiler that
+      # produces the published binaries -- the input where a substituted
+      # artifact matters most. So Go is installed the way goreleaser is:
+      # script/install-go downloads the exact archive for go.mod's `go`
+      # directive and refuses it unless its sha256 matches the value
+      # committed in the script, then puts .tool/go/bin on PATH for the
+      # steps below.
       - name: Install Go
-        uses: actions/setup-go@40f1582b2485089dde7abd97c1529aa768e1baff
-        with:
-          go-version-file: go.mod
-          # setup-go's module cache needs a runner-side cache backend.
-          # A release is cut rarely and a cold module download costs
-          # seconds; a release failing because a cache service is absent
-          # costs a re-tag. Off, deliberately.
-          cache: false
+        run: script/install-go
       - name: Install goreleaser
         run: script/install-goreleaser
       - name: Release
@@ -58,3 +46,8 @@ jobs:
           # It is deliberately not the runner's automatic token, which is
           # not guaranteed to carry that scope.
           GITEA_TOKEN: ${{ secrets.RELEASE_TOKEN }}
+          # Build with the toolchain install-go just verified, never a
+          # different one auto-downloaded from a `toolchain` directive:
+          # the point of the hash pin is that this exact compiler makes
+          # the release.
+          GOTOOLCHAIN: local