Build faillint from the main module instead of go install

[friedrichg]

What this PR does:

Alternative to #7815, not a supplement. Both fix the same breakage and only one should land. SungJin1212 diagnosed the problem there and the diagnosis is correct; this PR disagrees only about the mechanism. #7815 force-upgrades golang.org/x/tools inside a throwaway module in the Dockerfile; this declares faillint as a tool dependency so the version comes from our own module graph.

The problem: go install github.com/fatih/faillint@v1.15.0 resolves faillint's own go.mod, so it builds against golang.org/x/tools v0.30.0, whose decoder stops at pkgbits V2. Go 1.27 writes V4, so faillint fails with internal error: package "net/http" without types was imported from .... Go 1.24 through 1.26 all wrote V2, which is why the stale pin cost nothing for three releases. faillint has had no upstream commit since 2025-03, so its pin will never advance on its own and every future pkgbits increment breaks it again.

Declaring faillint as a tool dependency lets MVS pick x/tools from the main module, which already requires v0.47.0 (declares V4, and carries the corrected unified reader from CL 765504). The skew becomes structurally impossible rather than a version number someone must remember to bump in a Dockerfile whenever the Go base image moves. This is the same mechanism the Go project used for its own vendored x/tools in golang/go#49159.

x/tools is deliberately left at v0.47.0. Forcing v0.49.0 also drags x/net, x/crypto, x/text and x/mod forward, and x/net is a direct dependency that ships in the binary; lint tooling should not move it.

Cost: 364 KB of vendored source (13 x/tools packages, faillint's analyzer, and dmitri.shuralyov.com/go/generated). build-image/Dockerfile loses a step, and make lint calls go tool faillint.

Verified on Go 1.27.0: all 8 faillint checks pass; a control run (-paths context) still reports violations and exits 3, so the checks are not passing vacuously; go build -tags "netgo slicelabels" ./... is clean; go mod tidy and go mod vendor are idempotent, so make mod-check passes. Lint stays hermetic: go tool faillint was verified with GOPROXY=off against vendor/, so the build image still needs no module cache.

Note Makefile has a second instance of this bug class: make modernize runs golang.org/x/tools/gopls/...@v0.22.0, which is safe on Go 1.27 only because that pin happens to postdate the V4 decode fixes. Left alone here.

Which issue(s) this PR fixes:
N/A

Checklist

• Tests updated - n/a, build tooling. The faillint suite is itself the test, and the lint CI job exercises it.
• Documentation added - n/a
• CHANGELOG.md updated - n/a, build-image and lint tooling changes carry no entry, matching Upgrade golang to 1.27.0 and golangci-lint to 2.13.1 #7807
• docs/configuration/v1-guarantees.md updated if this PR introduces experimental flags - n/a, no new flags

AI usage disclosure

Per §3 of GENAI_POLICY.md: the investigation behind this change and the text of this description were substantially AI-assisted (Claude Code). Per §1, I verified the claims myself: I confirmed the vendored x/tools v0.47.0 declares V4 and has the corrected reader, reproduced the old failure on Go 1.27 in golang:1.27.0-trixie, and ran the faillint suite plus the control case locally on Go 1.27.0.