feat: render password_hash for users

[ariel-lahiany]

What

users.toml supports password_hash — a PostgreSQL SCRAM verifier (the value in pg_authid.rolpassword) used to validate client logins without keeping the plaintext password in the file. The chart's users documentation says it "supports all arguments from users.toml", but the template has no branch for it, so passwordHash is silently dropped from the rendered file and the user ends up with no credential at all.

This adds the missing branch, documents the key in values.yaml, and covers it in the test suite.

Why it renders independently of password / passwords

PgDog accepts both a plaintext password and a hash on the same user, and Server::new prefers the hash:

let hash = passwords.iter().find(|p| matches!(p, PasswordKind::Hashed(_)));
if let Some(hash) = hash { /* use the hash */ }

So passwordHash gets its own if rather than joining the password / passwords chain — the chart stays a faithful renderer of the config surface rather than imposing an ordering PgDog doesn't have.

Pairing

PgDog requires the backend hop to authenticate without a password when password_hash is set, which the schema states explicitly: "Server authentication must use RDS IAM or some other passwordless authentication." So this pairs with serverUser / serverAuth, and is not a replacement for serverPassword. The new fixture reflects that.

Testing

• helm lint clean
• All test/values-*.yaml fixtures still render
• New test/values-password-hash.yaml, picked up automatically by test.sh's glob
• Two assertions added, in the style of the existing multiple-passwords checks: the hash renders, and no plaintext password line is emitted for a hash-only user
• Rendered users.toml verified to parse as TOML

kubeconform wasn't available locally, so CI will be the first to run that step. The diff only changes the contents of a Secret's data value, so it shouldn't affect schema conformance.

Rendered output:

[[users]]
name = "app_user"
database = "primary"
password_hash = "SCRAM-SHA-256$4096:b6lksqhYfkXiN2hDMl3zfA==$9Rh0…=:V7jC7…="
server_user = "app_role"
server_auth = "rds_iam"

Unrelated observation

While validating, I noticed test/values-full.yaml uses username: and poolMode: instead of name: and poolerMode:. It renders syntactically invalid TOML — name = with no value — on main today. CI passes because kubeconform validates the Kubernetes Secret, not the TOML inside it. Happy to send that as a separate PR if useful; I left it out to keep this one focused.