feat(helm): make the controller ServiceAccount optional

[TarasLykhenko]

What

Adds two values for the controller ServiceAccount:

Value	Default	Effect
controller.serviceAccount.create	true	When false, the chart does not render the controller ServiceAccount.
controller.serviceAccount.name	"" (<fullname>-controller)	Name of the ServiceAccount the controller runs as and is bound to.

A new kagent.controller.serviceAccountName helper supplies the name to the ServiceAccount, the controller Deployment, and the getter, writer, leader-election and metrics-auth bindings.

Why

Some platforms create the controller ServiceAccount outside the chart, for example an IRSA or Workload Identity provisioner that owns the ServiceAccount and its role annotation. Today the chart always renders <fullname>-controller, and Helm refuses to install over a ServiceAccount it does not own:

ServiceAccount "kagent-controller" in namespace "kagent" exists and cannot be imported into the current release: invalid ownership metadata

controller.serviceAccount.annotations covers the case where the chart can own the ServiceAccount. It does not help when something else already does.

Compatibility

The defaults render exactly what the chart renders today, so existing installs don't change.

Testing

• New helm/kagent/tests/controller-serviceaccount_test.yaml covers: the default name, create: false, a custom name on the ServiceAccount and the Deployment, and each binding's subject.
• make helm-test: 386 tests pass.

[EItanya]

🤖 AI-generated review.

The change is focused and consistently updates the affected references. One small correctness issue with custom names is noted inline.

Validation: all 386 Helm tests passed, Helm lint passed, default manifests matched the base, and custom names worked across cluster-wide and namespaced RBAC. No live cluster testing.

[EItanya]

Can we quote the ServiceAccount name wherever the helper is emitted as a YAML value, and add a numeric-name test? A valid name such as "12345" renders as a YAML number even with --set-string controller.serviceAccount.name=12345. With controller.serviceAccount.create=false, I reproduced Kubernetes Deployment decoding failing with cannot unmarshal number into Go struct field Deployment.spec.template.spec.serviceAccountName of type string, so this prevents installing against that existing ServiceAccount. The ServiceAccount metadata and RBAC subjects use the same unquoted output and need the same treatment.

[jjamroga]

I agree with this point, after that we can absolutely 🚢

[TarasLykhenko]

Thanks, good catch. Quoted the name everywhere the helper is emitted, and added a numeric-name test (name: "12345") that asserts a string on each of them. With create=false and --set-string controller.serviceAccount.name=12345, the Deployment now passes a server-side dry run.