VAULT-48125-Fix: omit spec.namespace from VaultAuth when not configured

[catamtz]

Summary

The Helm chart always rendered spec.namespace in the VaultAuth resources it
creates, even when no Vault namespace was configured. The default value in
values.yaml is an empty string (""), so Helm emitted a bare namespace: key
with no value. When applied via server-side apply, Kubernetes deserialises this as
null, which fails the CRD schema validation:

Error: INSTALLATION FAILED: ... spec.namespace: Invalid value: "null":
spec.namespace in body must be of type string: "null"

This blocked any install of VSO where Vault namespaces are not in use — the common
case for open-source Vault deployments.

Changes

chart/templates/default-vault-auth-method.yaml

chart/templates/default-transit-auth-method.yaml

Wrapped spec.namespace in a conditional so the key is omitted entirely when the
value is empty. This matches the pattern already used for allowedNamespaces and
other optional fields throughout the chart:

# before
spec:
  namespace: {{ .Values.defaultAuthMethod.namespace }}

after

spec:
  {{- if .Values.defaultAuthMethod.namespace }}
  namespace: {{ .Values.defaultAuthMethod.namespace }}
  {{- end }}

The same fix is applied to the transit auth method template, which had the identical
issue under the storageEncryption path (persistenceModel=direct-encrypted).

test/unit/default-vault-auth-method.bats
test/unit/default-transit-auth-method.bats

Added a regression test to each file asserting that spec.namespace is absent from
the rendered manifest when no namespace value is configured.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}