ci: scan with the toolchain go.mod names

[leinardi]

What

golang/govulncheck-action always forwards its own go-version-input — which defaults to stable — to setup-go, and setup-go prefers go-version over go-version-file. Our go-version-file: go.mod was therefore ignored in both workflows, and the dry-run release said so in an annotation:

Both go-version and go-version-file inputs are specified, only go-version will be used

So the scan ran on whatever stable resolved to on the day, rather than the toolchain goreleaser builds the release with. The standard-library half of the report described a binary nobody ships.

setup-go + govulncheck are now called directly. Those two steps are everything the action did, minus the override, and they also drop its nested checkout of the repository.

Why pin the scanner

GOVULNCHECK_VERSION sits next to SVU_VERSION and is bumped by hand for the same reason: dependabot cannot see a go install argument. Pinning the tool does not pin what it knows about — the vulnerability database is fetched at run time. v1.8.0 run locally against this tree reports no vulnerabilities monmux calls.

Also here

The two release dispatch inputs were wordy because GitHub renders description as the form label and offers no separate help text. The explanation moved to a comment above each input, where it still serves whoever reads the file:

Version, e.g. 0.1.0 (empty: derive from the commits)
[ ] Dry run: build and sign, stop before the tag is pushed

The shortened labels only appear in the dispatch form once this is on main, since the form is read from the default branch.

Monitor writes

None. No step in either workflow runs monmux or touches a monitor, and this change adds none.

Testing

• make check-stage clean: actionlint, yamllint, prettier-yaml, markdownlint all pass
• govulncheck@v1.8.0 ./... run locally: No vulnerabilities found, exit 0
• The govulncheck job on this PR is itself the test of the replacement