fix: keep the module root a single package (tools.go -> go.mod tool directive)

[TangoEnSkai]

Context

close #162

tools.go pinned the gotestsum test runner with the pre-Go-1.24 "tools.go" idiom: a //go:build tools file declaring package tools in the module root, next to package dbsql. Two package names in one directory is only invisible to tools that honor build constraints, and two independent reports say downstream tooling does not:

• bazel/gazelle largely ignores build tags when it first resolves a directory's package, so vendoring the driver fails (the original report);
• golangci-lint on a project that uses a tools build tag internally hits a compile error on the driver's root package (Tools.go causes package conflict #162 (comment)).

Reproducible from a clean checkout of main:

$ go list -tags tools .
found packages dbsql (category_test.go) and tools (tools.go) in /path/to/databricks-sql-go

What

• Delete tools.go and pin the runner with the go.mod tool directive (Go 1.24+) instead. The module already declares go 1.25.0, so the directive is available.
• Keep gotestsum at v1.8.2 — this is a mechanism change, not a version bump, so it does not overlap with Bump gotest.tools/gotestsum from 1.8.2 to 1.13.0 #334.
• Add tools_test.go, a tripwire that loads the module root through go/build with the tools tag enabled and fails if the directory ever declares more than one package again. Verified it fails when tools.go is restored:

  --- FAIL: TestModuleRootIsASinglePackage (0.00s)
      tools_test.go:26: module root declares more than one package: found packages dbsql (category_test.go) and tools (tools.go) in .
  

No Makefile or CI change is needed: tool keeps the module in the build list, so the bin/gotestsum target's go build -o bin/gotestsum gotest.tools/gotestsum resolves exactly as before.

The only go.mod churn beyond the directive is go mod tidy moving the gotest.tools/gotestsum require line into the indirect block — that is what Go itself emits for a tool-only dependency (go get -tool on a scratch module produces the same annotation), since no package in the main module imports it.

Why

The tool directive is the supported replacement for the tools.go idiom and expresses the intent directly ("build-time tool", not "library the driver imports"), so the placeholder package that broke consumers is simply gone rather than renamed or relocated.

One honest caveat: go build -tags tools ./... still reports collisions, but they now come only from apache/arrow/go/v12, which ships its own tools.go (found packages arrow (array.go) and tools (tools.go) under the module cache). That is upstream and outside this repo's control; this change removes the one collision this module owns, which is the one both reporters hit on the driver's root package.

Completion Criteria

• go list -tags tools . succeeds (previously failed with the two-package error)
• go mod tidy is a no-op on the committed go.mod
• make test — 1097 tests pass, 2 e2e self-skipped (no warehouse credentials)
• make test-race passes
• ./bin/golangci-lint run (v2.12.2, as CI pins) — 0 issues
• make tools still builds bin/gotestsum from the pinned v1.8.2
• New test fails if tools.go comes back
• Commit signed off (DCO)