fix(helm): remove stale Chart.lock that pulls in conflicting Bitnami postgresql sub-chart

[jay-mtl]

Problem

The helm/hindsight/ chart contains a Chart.lock that references bitnami/postgresql@15.5.38 as a dependency, but Chart.yaml has no dependencies section. The chart has its own postgresql-statefulset.yaml template and does not use the Bitnami sub-chart.

Helm and GitOps controllers (e.g. Flux helm-controller) run helm dependency build whenever Chart.lock is present. This downloads and packages the Bitnami postgresql sub-chart into charts/postgresql/, causing two StatefulSets named hindsight-postgresql to be rendered:

1. templates/postgresql-statefulset.yaml — the chart's own template (ankane/pgvector, standard postgres security context)
2. charts/postgresql/templates/primary/statefulset.yaml — Bitnami (bitnami/postgresql, readOnlyRootFilesystem: true, runAsUser: 1001, selector: app.kubernetes.io/name: postgresql)

This causes two failures:

• Immutable selector conflict: both StatefulSets share the name hindsight-postgresql but have different spec.selector.matchLabels; the second apply is rejected by the Kubernetes API with spec: Forbidden: updates to statefulset spec for fields other than 'replicas'...
• CrashLoopBackOff: the Bitnami security context (readOnlyRootFilesystem: true) gets applied to the ankane/pgvector container, which needs to write to /var/run/postgresql at startup, causing: FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Read-only file system

Fix

Remove the stale Chart.lock. Since Chart.yaml lists no dependencies, the lock file is a leftover artifact and serves no purpose — it only causes the above conflicts for anyone using Helm dependency resolution (including Flux, ArgoCD with Helm, and plain helm install with dependency building enabled).

Testing

After removing Chart.lock, helm dependency build is a no-op and the chart installs cleanly with only the parent chart's own postgresql StatefulSet rendered.