golang-modernizelisted

# Go Modernization Modernize toward the project's intended compatibility target, not automatically toward the newest syntax. Preserve behavior unless the user explicitly includes a behavioral change. ## Establish the Target Before proposing changes: 1. Read `go.mod`, any `go.work`, CI configuration, release files, and supported-platform documentation. 2. Distinguish the module's `go` directive from the locally selected toolchain. Do not assume either one expresses the user's desired support policy. 3. If changing the supported Go version is in scope, confirm the target and compatibility consequences. Otherwise, stay within the existing directive. 4. Read the official release notes for every version crossed by the upgrade. Use [references/versions.md](references/versions.md) to evaluate candidates without relying on a stale feature catalog. 5. Inspect nearby conventions and existing migration decisions before introducing a new idiom. If the target version or downstream compatibility requirement is materially ambiguous, report the ambiguity before editing version-sensitive code. ## Choose Changes by Evidence Prioritize candidates in this order: 1. Removed, deprecated, or behavior-changing APIs that affect correctness or supportability. 2. Security and resource-safety improvements supported by the target version. 3. Standard-library replacements that remove a dependency or a meaningful amount of custom code. 4. Language and testing features that materially simplify the i