CI: vet does not cover tagged acceptance files, and there is no gofmt gate

[leggetter]

Summary

Two gaps remain in CI after #384 added go vet ./... to the unit-test job.

1. vet runs untagged only

go vet ./... does not build files behind build tags, and the acceptance suite has 22 of them (basic, metrics, connection, listen, project_use, manual, ...). So none of test/acceptance/ is vetted on a normal run.

go vet -tags basic ./... is clean today. The other 21 are unverified. Two real findings have already come out of that directory this week that vet would likely have caught earlier: two no-op append(sliceLiteral) calls, and an assertion reading the wrong stream.

Needs a decision on shape: a tag matrix, a comma-separated -tags list (risks duplicate symbols across tags), or vetting the acceptance package separately per tag.

2. No gofmt gate

Nothing checks formatting, which is how two files regressed during the 2026-09-01 work and were only noticed by hand.

This cannot simply be switched on: roughly 40 files on main are already unformatted, so a gate fails immediately. It needs a repo-wide gofmt -w first, which is a large mechanical diff best landed on its own rather than inside a feature branch.

Suggested order

1. Repo-wide gofmt -w, alone, no behaviour changes.
2. Add gofmt -l to the unit-test job, failing on non-empty output.
3. Decide the tagged-vet shape and add it.

[leggetter]

Concrete instance found while working on #392, worth folding into this issue's scope rather than filing separately.

test/acceptance/request_test.go:356 calls triggerEvent, which is defined in an event-tagged file. So:

go vet -tags request ./...          → vet: request_test.go:356:2: undefined: triggerEvent
go vet -tags "request event" ./...  → clean

It compiles in CI only because slice 1 happens to run request and event together (SLICE1_TAGS="request event" in run_parallel.sh). The request tag has a hidden dependency on the event tag, and resliceing would break it with no warning.

This strengthens the case for the vet-per-tag gate proposed here: a per-tag vet would have caught the coupling when it was introduced, whereas the current slice-level run hides it. Worth vetting each tag individually rather than only the slice combinations, since the slices are a CI-parallelism decision and not a statement about what the tags mean.

Not urgent — nothing is broken today — but it is the kind of latent coupling that surfaces as a confusing CI failure much later, after whoever wrote it has moved on.

(Found by Claude while working on #392, on Phil's behalf.)