fix(deploy): reject weak passwords embedded in explicit datastore URLs #86

Context

Follow-up from #84. The deployment credential guard (scripts/check_deploy_credentials.py) applies _is_weak_password() only to the POSTGRES_PASSWORD, POSTGRES_READONLY_PASSWORD and REDIS_PASSWORD component variables. Passwords supplied inside an explicit URL bypass that policy:

• DATABASE_URL password: only an exact match against WEAK_PASSWORDS is rejected (no placeholder-prefix or minimum-length check).
• DATABASE_READONLY_URL: only presence and reuse of the application password are checked.
• REDIS_URL: presence only, so redis://:short@host:6379/0 passes the 12-character policy.

The inverse also fails: a deployment that configures only explicit URLs with strong credentials is reported as missing all three *_PASSWORD variables.

Verified on the current tip:

audit_credentials({...strong component vars..., "REDIS_URL": "redis://:short@h:6379/0"}) == []
# and DATABASE_URL="postgresql+asyncpg://u:change_me@h/db" is accepted

Why it matters

The guard's stated contract is to "fail closed on placeholder or default deployment credentials". Today it only enforces that for the component form. Compose always uses components, so this is defence-in-depth rather than an exploitable compose bug.

Acceptance criteria

• Apply the same _is_weak_password() policy (empty, default/known, placeholder prefix, minimum length) to passwords parsed from DATABASE_URL, DATABASE_READONLY_URL and REDIS_URL.
• Decide and document whether *_PASSWORD is still required when an explicit URL carries credentials (avoid the false positives above).
• Add regression tests to tests/unit/test_deploy_credentials.py covering weak URL passwords and the explicit-URL-only configuration.