chore: resolve staticcheck findings and repair the make targets

[t2y]

Summary

This picks up @rc4's work in #608 and adds four follow-up commits.

All five of @rc4's commits are preserved here with their original authorship; the staticcheck cleanup itself is entirely their work.

@rc4, if you would rather keep #608 and pull these follow-ups into it, say so and I will close this one.

What comes from #608 (@rc4)

At the merge base, staticcheck ./... reports the following in v3. After #608 it reports nothing.

Check	Count	Fix
SA1019	3	io/ioutil → io / os
SA1019	3	deprecated ntlmssp.ProcessChallenge, ProcessChallengeWithHash and GetDomain → NewAuthenticateMessage
ST1005	6	lowercase the first word of error strings
ST1019	1	encoding/hex imported twice

The golangci-lint job also reports staticcheck's QF checks, which #608 clears as well: QF1002 (1), QF1003 (4), QF1006 (1) and QF1008 (4).

Beyond that it fixes checks that are off by default (ST1016, ST1020, ST1021, and one ST1003 on a local in a test) and modernizes interface{} → any, reflect.Ptr → reflect.Pointer and a counting loop to for range 100.

The three remaining ST1003 findings (SyncInfoSyncIdSet, ControlSyncInfoSyncIdSet, SyncIdSet) are left alone on purpose, since they are exported and renaming them would break the API.

What this PR adds

chore(gssapi): clean up shadowed identifiers and a !false return

The Client receiver was named client, and the constructors bound locals named client and keytab. Both shadow the imported packages of the same name. After #608 applied QF1008, client.Client.Destroy() became client.Destroy(), which reads like a package-level call. Renaming the receiver to c and the locals to cl and kt removes the ambiguity.

The same file returned !false in the IsKRBError branch, where the sibling branch returns a plain true.

chore: replace golint with staticcheck in the lint target

make lint ran golint, which is deprecated and frozen (golang/go#38968). It now runs staticcheck ./..., following the same change made in go-ldap/ldif#30. The shell wrapper that turned non-empty output into a failure is gone, since staticcheck exits non-zero on its own.

Two adjustments were needed:

• The target runs inside v3/, because the repository root holds no go.mod.
• golang.org/x/crypto/md4 carries a //nolint:staticcheck comment, which only golangci-lint understands. A //lint:ignore SA1019 was added beside it so that plain staticcheck stays quiet too. The //nolint one stays for CI.

chore: run the Go targets inside the v3 module

install, build, test and vet all ran at the repository root, where go fails with directory prefix . does not contain main module. They now cd into v3/ the way fuzz and lint already did, through a MODULE_DIR variable.

.PHONY also listed test twice and was missing fuzz, local-server and stop-local-server.

chore: run the tests in every package of the module

go test . covered only v3, so nothing ever ran the tests in v3/gssapi. That includes the regression test for the UnmarshalWrapToken offset overflow added in #602, where a checksumL above 65519 wrapped the uint16 offset and panicked the bind goroutine.

The Makefile and .github/workflows/pr.yml now use ./..., which also makes go vet and go build cover that package in CI.

Notes for reviewers

• The ST1005 fixes change error strings reachable through the public API, such as GetLDAPError returning Empty packet. Callers comparing those strings will need updating.
• The NTLM change reads like a behavioral change but is not. In go-ntlmssp v0.1.1, ProcessChallenge and ProcessChallengeWithHash are //go:fix inline wrappers whose bodies are
  exactly the new calls, and ProcessChallenge ignores the domainNeeded argument that GetDomain produced.
• No test covers the NTLM challenge bind path, so that equivalence rests on reading the dependency.

Testing

• make lint, make vet, make build and make fmt pass.
• make test now compiles and runs both packages. v3/gssapi passes; the v3 tests need a directory server from make local-server.

[rc4]

No concerns from me - however we can land my (admittedly small) improvements works for me :-)

A suggestion - I assume most people use VSCode for development, would it be an opportune time to add a shared .vscode config for linting/formatting? I should have what I was using kicking around somewhere...