Problem

createUser and updateUser accept passwords that fail SASLprep (RFC 4013) and store a credential no standard client can use. PrehashPassword in pg_documentdb/src/commands/users.c runs pg_saslprep and, when it returns SASLPREP_PROHIBITED or SASLPREP_INVALID_UTF8, quietly builds the SCRAM secret from the raw bytes. Clients run SASLprep before SCRAM and refuse such passwords, so the call reports success and every login fails, for example ValueError: SASLprep: failed prohibited character check for a password containing an emoji.

Fix

Raise a bad-value error in PrehashPassword when SASLprep fails, rather than falling back. This covers every caller: wire-protocol createUser/updateUser, the container and the native installer. Passwords SASLprep accepts, including non-ASCII ones like pässword, keep working.

Why it matters for packaging

The packaging tools can't carry SASLprep's Unicode tables, so #731 refuses every non-ASCII password before setup as a stopgap. Once the backend rejects exactly the failing passwords, the tools can drop that rule and keep only the line-ending and control-character checks.

Acceptance criteria

• createUser and updateUser reject a password that fails SASLprep with a clear bad-value error, before any role is created or changed.
• Non-ASCII passwords that pass SASLprep are accepted and authenticate.
• Regression tests on PostgreSQL 15–18.
• The packaging tools relax their ASCII-only rule (follow-up to Align native installer username and password-file validation with backend and client semantics #731).