Local gates use the machine's Go, not the declared 1.26.5, and tell you to commit the difference

[vishr]

just check and the pre-push hook disagree with each other on any machine
whose default Go is newer than the 1.26.5 declared in go.mod, and the failure
they produce points the reader at a fix that makes things worse.

Reproduction

go.mod declares go 1.26.5 and carries no toolchain directive, so any newer
Go runs as itself rather than downloading the declared one. On a machine with
Go 1.27.0:

$ just notices-check
notices: THIRD_PARTY_NOTICES is stale; run `just notices`

$ GOTOOLCHAIN=go1.26.5 just notices-check
THIRD_PARTY_NOTICES matches the release dependency graph

The committed file is correct. The local toolchain is what disagrees.

What actually differs

Go 1.27.0 selects one module that 1.26.5 does not:

+ Go: github.com/apparentlymart/go-textseg/v17 v17.0.1

Running just notices on 1.27.0 adds that entry and its full licence block — 27
lines — to THIRD_PARTY_NOTICES.

Why this is worth fixing rather than remembering

The message says run just notices``. Following it produces a diff that looks
plausible, is not a dependency change anyone made, and — if committed — ships a
third-party licence file describing a dependency graph the released binary does
not have. It is the one generated artifact in the repo where being wrong has a
consequence outside the build.

It has already cost real time. Earlier in the same session that produced #191, I
read this failure as "upstream main is red with stale notices" and reported
that to the user. It was not; my toolchain was. The wrong conclusion was only
caught by regenerating on 1.26.5 and finding the result byte-identical to
upstream's.

Second cost, same day: git push on a green branch was rejected by the
pre-push hook for this reason, on a commit whose GOTOOLCHAIN=go1.26.5 just check had already passed.

Why the gates disagree

• CI pins the toolchain — actions/setup-go with go-version-file: go.mod
  installs exactly 1.26.5, so the workflows are always right.
• just check and lefthook's pre-push inherit whatever Go is on PATH.

So CI is correct and local is not, which is the wrong way round for a check
whose whole purpose is to fail before CI does. There is no GOTOOLCHAIN
reference anywhere in justfile, the lefthook config, or the workflows.

Suggested fix

Pin it where the recipes run, so the local gate matches the release build
without anyone having to know:

1. Set GOTOOLCHAIN from go.mod in the justfile (an export at the top, or
   on the Go-invoking recipes), so just check, just notices and
   just notices-check all agree with CI.
2. Alternatively add a toolchain go1.26.5 directive to go.mod, which makes
   every Go invocation everywhere use it — broader, and worth considering on its
   own merits.

Option 1 is narrower and sufficient. Option 2 also fixes bare go test and
go build run by hand, which have the same exposure for anything toolchain
sensitive.

Whichever is chosen, notices-check's failure message should say that a
toolchain mismatch is a possible cause, rather than only offering just notices. A message that names the wrong remedy is what turned this from a
papercut into a wrong report.

[vishr]

Triage verification: the core report is valid. Comparing the generated Go component set under Go 1.26.5 and Go 1.27.0 differs exactly by github.com/apparentlymart/go-textseg/v17 v17.0.1. Two corrections for implementation: just check and the pre-push hook do not inherently disagree; both inherit the caller environment, and they diverged in the reported session because only the standalone invocation was explicitly pinned. Also, adding toolchain go1.26.5 to go.mod would not force a newer default toolchain to downgrade; that directive only takes effect when the default is older. An exact GOTOOLCHAIN=go1.26.5 setting in the justfile or an equivalent wrapper is the applicable pin. No duplicate issue or fixing PR found. Leaving open as a local-gate reproducibility bug.