fix(auth): POST /login 500'd on any malformed password hash — found by the journey on tick one #5475

The synthetic journeys went live and caught a real production bug within five minutes: journey:login-form reported "login handler returned 500 on a bad password" on its very first tick (visible on /status, and the new spine alerting emailed the owner).

Root cause: Bun.password.verify throws on a hash it cannot parse, and no call site caught it. The journey's probe user carried a deliberately malformed hash, so the wrong-password POST hit the throw — and any row with a non-bcrypt password_hash (legacy imports, SCIM edge cases, manual rows) would 500 a real user's login the same way, while leaking that the account exists and is unusual.

Fixes, defence in depth:

• verifyPassword() returns false on unparseable hashes — cannot-parse cannot-match (regression tests: malformed marker, empty string, plaintext legacy value)
• the probe user now stores a valid bcrypt hash of 48 discarded random bytes — unloginable in practice, structurally sound — and heals the row the first version created

🤖 Generated with Claude Code