Support PostgreSQL connection secrets

[iplay88keys]

Important

This PR requires a substrate bump after this upstream PR merges: agent-substrate#1752

Summary

• Add postgres.connectionStringSecretRef so the chart can read the Substrate runtime/DML connection from a Kubernetes Secret instead of placing credentials in a ConfigMap.
• Add optional postgres.ddlConnectionString and postgres.ddlConnectionStringSecretRef settings for a separate schema-owner connection used by migrations and maintenance.
• Pass the DDL connection to ateapi through ATE_API_POSTGRES_DDL_CONNECTION_STRING and --postgres-ddl-connection-string=@env.
• Keep postgres.schema in the existing ConfigMap and default enabled Secret references without a name to the release-scoped <release>-postgres-connection Secret.
• Reject conflicting inline and Secret-backed settings, a missing external runtime connection, and a DDL connection without an explicit runtime connection.
• Add Helm unit coverage and run the chart tests in the existing Helm CI workflow.

This lets parent charts provide PostgreSQL credentials through normal Kubernetes Secret references without coupling Substrate to a specific parent chart.

Configuration

The existing single-connection configuration remains supported:

postgres:
  enabled: false
  schema: substrate
  connectionStringSecretRef:
    name: substrate-postgres
    key: connectionString

For separate runtime/DML and DDL roles, both connections can come from the same Secret under different keys:

postgres:
  enabled: false
  schema: substrate
  connectionStringSecretRef:
    name: substrate-postgres
    key: runtimeConnectionString
  ddlConnectionStringSecretRef:
    name: substrate-postgres
    key: ddlConnectionString

When the DDL connection is omitted, ateapi uses the runtime connection for both purposes. With separate roles, the DDL role owns the schema and creates its objects; after migrations, ateapi grants the runtime role the table and sequence permissions it needs. This avoids requiring operators to update grants whenever a migration adds a table.