style: fix gofmt drift and gate formatting in CI

[thanhleviet]

Five files on main were not gofmt-clean. This formats them and adds the check that would have caught it.

style: apply gofmt to five drifted files

Ordinary formatting, no version-specific rules involved:

• internal/cli/download_cmd.go - var-block alignment went stale when maxSamples int was added.
• internal/index/query.go - userColToSQL map alignment went stale when the longer Completeness_General key was added.
• internal/cli/query_cmd.go - pq "…/internal/parquet" was sorted by its alias instead of its import path, so it sat above "…/internal/output".
• internal/query/executor_test.go, internal/selfupdate/selfupdate.go - alignment only.

Verification:

• git diff -w across all five files shows nothing but the one import line, so everything else is whitespace.
• go build -trimpath ./cmd/atb produces a byte-identical binary before and after (9b058488…).
• Go 1.23's gofmt and Go 1.25's gofmt flag the same five files and emit byte-identical output, so this is not a toolchain difference.
• go vet ./... clean, go test ./... green across 22 packages.

ci: check formatting in the lint job

Nothing in the repo checked formatting, which is why the drift survived:

• The CI Lint job ran only go vet ./... and go build ./....
• make lint runs golangci-lint run ./... with no config file, and gofmt is not among golangci-lint's default linters.
• CI never invokes make lint, so the two things named "lint" had diverged anyway.

The new Format check step runs gofmt -l . and prints the offending paths. Tested both directions against a git archive export, which is exactly what CI checks out: exit 1 listing all five files against 4c77c14, exit 0 against this branch.

The job's go-version moves from "1.23" to "1.25". go.mod declares go 1.25.0, so with the default GOTOOLCHAIN=auto every go command in that job already downloaded and switched to 1.25 - GOTOOLCHAIN=go1.23.0 go build fails outright with go.mod requires go >= 1.25.0. gofmt is a standalone binary and does not follow that switch, so a "1.23" pin would check formatting with a different gofmt than the version the module requires. The other workflows (release.yml, pages.yml, docs.yml) already pin "1.25".

Not changed

The test matrix and the coverage job still say go: "1.23", which is misleading for the same reason - they auto-upgrade to 1.25 and cannot run 1.23. Correcting that is a statement about which versions the project supports, so it is left alone here.

No CHANGELOG entry: no user-visible behavior changes.