feat(chart): pg password via ExternalSecret/OpenBao (A-Chunk 1)

Per-instance Postgres password sourced from OpenBao via External
Secrets Operator. Dual-mode for the migration window:

  - postgres.passwordVaultPath unset → legacy postgres-secret.yaml
    renders with .Values.postgres.password (helm lookup + random
    fallback, bit-exact existing behaviour for live instances).
  - postgres.passwordVaultPath set → postgres-password-externalsecret.yaml
    renders an ExternalSecret that produces the same <release>-pg
    Secret (POSTGRES_USER/PASSWORD/DB) from OpenBao path
    `tenants/<tenant.id>/instances/<instance.code>/pg`.

Exactly one of the two templates ships per instance (mutually
exclusive `if`s on .Values.postgres.passwordVaultPath). The Postgres
StatefulSet envFroms <release>-pg unchanged.

OpenBao policy already grants the per-cluster ESO read on
`v3/data/tenants/<tenantID>/*` (buildEsoPolicy in tower's
openbao_auth_setup.go) — the new instances/<code>/pg subpath is
covered. No policy change required.

A `required` directive on the ExternalSecret asserts tenant.id is
present when passwordVaultPath is set — fails loud at helm template
time if Tower forgot to populate it.

deletionPolicy: Retain on the ExternalSecret. Postgres PGDATA on
disk hashes to the password in the Secret; an accidental ESO
removal must not cascade into the Secret disappearing.

Chart 0.1.6 → 0.1.7. Verified locally: helm template both modes,
helm lint clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

values.yaml

@@ -17,6 +17,13 @@ instance:
   # `instance.size: medium` (etc); they don't have to know the numbers.
   size: small
 
+# tenant — owning tenant identity. Currently only required when
+# postgres.passwordVaultPath is set (the ESO path needs to know which
+# tenant subtree to read from OpenBao). Tower writes `tenant.id` into
+# every new overlay; legacy overlays without ESO leave this empty.
+tenant:
+  id: ""
+
 # The named-size table. Single source of truth for what each instance
 # tier actually gets. Adjust here, ALL future instances pick up the
 # new defaults on next reconcile. Existing instances keep their
@@ -159,7 +166,34 @@ postgres:
   database: postgres
   # If empty, the chart auto-generates on first install and re-reads
   # the existing Secret on subsequent upgrades (lookup pattern).
+  # Ignored when `passwordVaultPath` is set — ESO sources the password
+  # from OpenBao instead.
   password: ""
+  # passwordVaultPath — when set, the chart renders an ExternalSecret
+  # pulling the password from OpenBao at
+  # `tenants/<tenant.id>/instances/<instance.code>/pg` (field
+  # `password`). The legacy postgres-secret.yaml template is gated
+  # off; the ExternalSecret produces the same `<release>-pg` Secret
+  # shape so postgres-statefulset.yaml is unchanged.
+  #
+  # When empty (default), the chart falls back to the legacy
+  # postgres-secret.yaml path using `.password` above. Tower sets
+  # this field on every new instance starting v0.77; pre-v0.77
+  # instances stay on the legacy path until migrated by the one-shot
+  # tool (Chunk 3 of A-OpenBao).
+  #
+  # The actual path resolution is hardcoded in the
+  # postgres-password-externalsecret.yaml template; this field is
+  # the on/off toggle. Setting it to any non-empty value is
+  # equivalent ("use ESO for this instance"); the path string itself
+  # is currently advisory (it's the OpenBao subtree the operator can
+  # `bao kv list` to find the password).
+  passwordVaultPath: ""
+  # externalSecretsStoreRef — ClusterSecretStore name the
+  # ExternalSecret references. Provisioned by cluster-platform-v3
+  # under `openbao-platform` by default. Override only on clusters
+  # that name the store differently.
+  externalSecretsStoreRef: openbao-platform
   storage: 10Gi
 
 backups: