feat(infra): install CloudNativePG operator and shared-cluster

[TineoC]

Step 4 of CodeForPhilly/balancer-main#526 — stand up CloudNativePG on this cluster. Nothing cuts over here. Production Balancer keeps reading from AWS RDS; this only puts the destination cluster in place beside it.

Opened as a draft: this adds a shared-infra component to the live cluster and wants @themightychris's eyes before it merges.

What lands

Path	What
.holo/sources/cloudnative-pg-chart.toml	chart source, pinned refs/tags/cloudnative-pg-v0.28.0
.holo/branches/k8s-manifests/_infra/cloudnative-pg/operator.toml	projects charts/cloudnative-pg → _infra/cloudnative-pg/operator
.holo/lenses/cloudnative-pg.toml	helm3 lens, include_crds = true, release cloudnative-pg in ns cloudnative-pg
_infra/cloudnative-pg/namespaces.yaml	the namespace
_infra/cloudnative-pg/shared-cluster.yaml	Cluster/shared-cluster, 2 instances, PostGIS 18 image, 20Gi
.claude/CLAUDE.md	the "No cnpg / shared-cluster on this cluster yet" bullet is no longer true

All of it mirrors cfp-sandbox-cluster, which has been running this exact shape since June. The Cluster CR and namespace sit outside the lens input root, so they pass through raw while the chart gets rendered.

Two deliberate omissions

No managed.roles. The balancer role names a passwordSecret that has to be sealed into cloudnative-pg.secrets/ first — and cnpg reports a role reconcile error for as long as that Secret is absent. The role and the Database CR land together in the follow-up PR, after the seal.

No backup: stanza. It needs an object store bucket and credentials that do not exist yet. Worth stating plainly: this cluster has no backups, and neither does sandbox. Moving production data here before that lands would trade RDS's automated snapshots for nothing. That is tracked as a blocking step in CodeForPhilly/balancer-main#526.

One difference from sandbox

storageClass: linode-block-storage-retain is explicit here; sandbox takes the cluster default. On a production cluster the -retain reclaim policy is the difference between a deleted PVC being an incident and being an outage. Flagging it since it is the one line not copied verbatim.

Verification after deploy

kubectl -n cloudnative-pg get pods                    # operator Running, shared-cluster-1/-2 Running
kubectl -n cloudnative-pg get cluster shared-cluster  # STATUS: Cluster in healthy state
kubectl get crd | grep cnpg                           # clusters, databases, backups, poolers...
kubectl -n cloudnative-pg exec shared-cluster-1 -- psql -tAc "select version()"

No existing workload is touched — no app in this repo references cnpg yet.

Sequencing

1. this PR — operator + empty cluster
2. seal balancer-db-credentials into cloudnative-pg.secrets/ (needs cluster access; not a PR I can open)
3. follow-up PR — managed.roles + balancer/cnpg/database.yaml with the vector extension, plus the balancer/ split into app/ + cnpg/ that sandbox already has
4. pg_dump RDS → pg_restore → row-count parity check
5. re-seal balancer.secrets/balancer-config.yaml with the cnpg host, bump the image off 1.1.5
6. object store + ScheduledBackup, then decommission RDS

Steps 2, 4 and 5 need cluster and AWS credentials, so they cannot be delivered as PRs.