Helm chart fails to render and cannot disable bundled PostgreSQL for an external DB

The Helm chart in helm/jackson fails to render from its checked-in defaults, including when an external PostgreSQL connection URL is supplied.

Reproduced on main at e13ed6541ec026dc37243f975b6d88be9488b687:

helm template polis helm/jackson \
  --set jackson.dbUrl=postgres://polis:example@external-db.example:5432/polis

Result:

Error: template: jackson/templates/dep-helm.yaml:77:13:
executing "jackson/templates/dep-helm.yaml" at <.Values.postgres.ports>:
nil pointer evaluating interface {}.ports

values.yaml has no postgres section, while templates/dep-helm.yaml unconditionally renders a PostgreSQL Service and StatefulSet using .Values.postgres.*. Supplying jackson.dbUrl only changes the application's and migration Job's DB_URL; it does not suppress those database resources. Supplying the missing PostgreSQL values allows rendering, but still emits the bundled database even for an external connection.

The chart also unconditionally creates the application's Secret and references it from both the Deployment and migration Job. There is no existing-Secret option for installations where credentials are managed externally.

Following CONTRIBUTING.md, I would like to agree on the approach before submitting code. Proposed narrowly scoped chart changes:

• Add a documented postgres.enabled switch and guard the bundled PostgreSQL Service and StatefulSet (including its volumeClaimTemplates).
• Provide complete defaults for the bundled-database mode and make its default connection URL match the release-derived Service name, while preserving explicitly supplied external URLs.
• Add an optional jackson.existingSecret reference, used consistently by the Deployment and migration Job; skip rendering the chart-managed application Secret when it is set.
• Document external PostgreSQL and existing-Secret examples without any vendor-specific infrastructure dependencies.
• Add render regression checks covering defaults, bundled PostgreSQL, external PostgreSQL with bundled resources disabled, and an externally managed Secret used by both consumers.

Would this approach be welcome? Do you prefer retaining the bundled database as the default or making it opt-in? I can prepare a PR once the intended compatibility behavior is agreed.

Start with helm/jackson/values.yaml and helm/jackson/templates/dep-helm.yaml, then review how the Deployment, migration Job, PostgreSQL resources, and application Secret are wired together. Use the reported helm template command as the first reproduction. Done means the chart renders from defaults and for external PostgreSQL and externally managed Secret configurations, with the intended resources and references present or omitted consistently.