fix(controller): render the RBAC the metrics proxy needs to answer a scrape

[duckhawk]

What

helm_lib_module_controller_rbac now renders the ClusterRoleBinding that the kube-rbac-proxy sidecar needs in order to answer a scrape, gated on a new optional controllerMetricsProxyPort key in its config. Chart bumped to 1.72.22.

Why

The two controller helpers are meant to be used together and disagree about who grants what:

• helm_lib_module_controller_manifests adds a kube-rbac-proxy sidecar in front of the manager's metrics port whenever controllerMetricsProxyPort is set. The proxy authenticates and authorises every request by creating a TokenReview and a SubjectAccessReview.
• helm_lib_module_controller_rbac renders the ServiceAccount and its bindings — and neither of those two verbs is among them.

So every module using the pair has to know to add a binding to d8:rbac-proxy by hand, and the ones that do not get a proxy that fails closed with 401 on every scrape.

The failure mode is what makes this worth fixing in the library rather than in each module. Nothing looks broken: the manager publishes its metrics, the ServiceMonitor selects the Service, the pod is Ready, and the controller's own log is silent. The only symptom is up == 0 on the module's job and a TargetDown alert that has been firing since the module was installed. Found in sds-object after TargetDown had been up for two weeks; the same binding is missing today in eight more storage modules that call these helpers.

How

{{- $rbacConfig := dict
  "controllerMetricsProxyPort" (int .Values.myModule.internal.controllerMetricsProxyPort)
  "roleRules" (list ...)
  "clusterRoleRules" (list ...)
}}
{{ include "helm_lib_module_controller_rbac" (list . $rbacConfig) }}

Pass the same value already given to helm_lib_module_controller_manifests. It is not used as a port — it is how the RBAC helper learns that a sidecar exists. Gating on it rather than rendering unconditionally keeps a controller without a metrics proxy from gaining the ability to review tokens, and keeps the rendered output of every current caller byte-identical until it opts in.

The binding is named d8:<module>:<fullname>:rbac-proxy, the convention the core modules (cert-manager, cni-cilium, node-manager, …) already follow. A module that carries this binding by hand today can therefore drop its copy and set the key in the same commit: the object keeps its identity and Helm adopts it rather than replacing it. Doing only one of the two would render the binding twice under one name, which Helm rejects.

Tests

Three cases added to helm_lib_module_controller_rbac_test.yaml: no binding without the key (5 documents, as before), the binding with the key (6 documents, correct roleRef and subject), and the naming with a custom fullname.

make ci/tests/unit: 407 tests in 86 suites pass. Snapshots unchanged, make doc/diff clean.