chore(lint): enable modernize linter and fix its findings

Summary

Enables the modernize linter in .golangci.yml and fixes every finding it reports: 31 across 15 files.

All of the code changes are mechanical and behavior-preserving. They are split into one commit per modernize sub-check, so each can be reviewed as a single kind of transformation:

  • any: replace interface{} with any
  • fmtappendf: replace []byte(fmt.Sprintf(...)) with fmt.Appendf
  • mapsloop: replace map copy loops with maps.Copy
  • stringsseq: range over strings.SplitSeq / bytes.SplitSeq instead of Split
  • rangeint: range over an int instead of a counting for loop
  • slicesbackward: use slices.Backward for reverse iteration
  • newexpr: make client.Ptr an inlinable wrapper around new(expr)

Why

  • The repo moved to a Go 1.26 baseline in !549 (merged), which makes newer standard library and language constructs available everywhere. modernize finds the call sites still written the older way.
  • Enabling the linter without fixing its findings would leave make go-lint red, so both belong in the same change.

How

Two things a reviewer cannot pick up from the diff:

  • make go-lint under-reports the findings. golangci-lint's default issues.max-same-issues: 3 truncates each sub-check to three reports, so the command shows 17 of the 31. The full set comes from golangci-lint run --max-same-issues=0 --max-issues-per-linter=0 ./.... This MR leaves the default in place, so the same cap applies to future findings.
  • client.Ptr deliberately has no //go:fix inline directive. The newexpr fix suggests adding one, which would have gopls and go fix rewrite every client.Ptr(x) call site to new(x). Returning new(v) on its own already satisfies the linter, and the directive would push a much wider change onto the callers of an exported helper, so it is left off.

One commit is not a clean single sub-check: the rangeint fix to Environment.ValueOf's outer loop ships with the slicesbackward commit, because the inner slices.Backward(env.mutations) rewrite depends on having the element in hand rather than the index. Lock ordering in readLockEnvChain is unchanged.

Merge request reports

Loading
Loading