CLOUDP-423293: Add multicluster generate-member-resources plugin command

[m1kola]

Summary

First slice of the multi-cluster configuration tooling work, stacked on feature/mc-installation-ux.

Adds kubectl mongodb multicluster generate-member-resources: a local, non-mutating command that renders the RBAC a member cluster needs and writes it to stdout (for kubectl apply / GitOps). The operator Helm chart is embedded into the plugin as a Go package (helm_chart) and rendered with the Helm SDK, so the chart stays the single source of truth for RBAC (no duplication with the plugin). Member RBAC uses additive mck-member-<cluster>-* names; the fixed-name workload SAs are emitted too (interim — see docs/dev/multi-cluster-config-tooling.md). Member templates are gated behind memberCluster.enabled (set only by the plugin), so existing installs and E2E are unaffected.

Proof of Work

• go test ./pkg/kubectl-mongodb/memberresources/... — render across single/multiple/all watched-namespace scopes, an embed-vs-disk drift guard, and a helm CLI parity check.
• go run ./cmd/kubectl-mongodb multicluster generate-member-resources ... produces valid RBAC (verified with kubectl apply --dry-run), with no extra scripts.
• ct lint passes; the plugin cross-compiles for linux amd64/arm64/s390x/ppc64le; the default helm render is unchanged (no mck-member resources).

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• Have you added changelog file?

---

[m1kola]

This is a temporary file for me to help keeping track of work items around multi-cluster. The plan is to remove it at the end.

[m1kola]

This is transient state and is not ideal.

One of the issues we have right now is that kubectl mongodb embeds some RBAC which is mostly duplication of RBAC we have in the base installation (operator-roles-base.yaml, operator-roles-pvc-resize.yaml, etc) and this duplication goes out of sync. Today it is Go definitions in pkg/kubectl-mongodb/common/common.go.

With this template we move it to helm chart (good, what we want), but we still have duplication (not what we want).

For now I want to leave it as is, but I want to try and de-duplicate it later by using the same template for both base installation with helm install (single-cluster setup) and multi-cluster so we don't have to add new roles in multiple places. I want to do it at a later stage, once we start consuming this CLI. I added a follow-up slice to the doc in #1388

[josvazg]

LGTM

Probably a nitpick anot work any changes, but just in case

memberCluster.* values are intentionally undocumented/absent from values.yaml (plugin-internal only, guarded with default dict in the template). This is a reasonable design choice but slightly fragile: if someone renames memberCluster.enabled/memberCluster.name in the Go code without updating the template (or vice versa), there's no compile-time link — the TestHelmTemplateParity/TestEmbeddedChartMatchesDisk tests are the only safety net. That's mitigated well already, just noting it's stringly-typed by nature (values map has map[string]any, no shared struct).