expand and version the development container toolchain #14125

Describe the feature or problem you’d like to solve

The development container provides the core Go environment, but it does not provision every tool needed for normal contributor workflow, and several inputs can change independently of this repository:

• The Go image uses the floating 1.26 tag, the SSH feature uses :1, and the image currently supplies tools such as golangci-lint as latest. Rebuilding at different times can therefore select different versions, while CI separately pins golangci-lint 2.12.2.
• make lint assumes a compatible linter is already on PATH.
• Checked-in generators require moq, goimports, protoc, protoc-gen-go, and protoc-gen-go-grpc, but their versions and installation are not project-owned. The RPC instructions currently use moq@latest.

goal is for contributors using the repo-provided development container to be able to build, test, lint, and regenerate checked-in code with tools whose availability and version policy are defined by the repository. This would reduce setup work and ensure contributors use tooling that aligns with how CI runs

Proposed solution

Define authoritative versions or an explicit update policy for the base image, Dev Container features, linter, and generation tools, and make the development container consume them. CI should use the same declarations or verify that its versions remain aligned.

The mechanism could be Go tool directives, Dev Container features or a Dockerfile, a bootstrap script, or another shared manifest

Additional context

• Issue #5582 and PR #5592 introduced the container for a consistent Go environment.
• In PR #6405, maintainers removed a second gh installation because contributors build bin/gh and a system version could be stale or confusing.
• Issue #11165 notes that container image availability can lag Go releases.

If this direction is right, could maintainers clarify the preferred implementation path?