#21: make the auth service actually authenticate

The F4 auth service issued a valid session for any email and any password,
and accepted any non-empty string as a second factor. Reproduced against
the router before touching it: an invented password plus the code "000000"
returned a SUPER_ADMIN token that opened /api/v1/admin/dashboard.

Passwords. Hashing moves from PBKDF2 to Argon2id via hash-wasm, which is
what PLAN.md section 9 and the Go service already use - the previous
scheme meant a password set through the mail stack could never verify
here. Interoperability was checked in both directions before adopting the
library: a hash written by alexedwards/argon2id verifies in Node and one
written here verifies in Go. hash-wasm is pure WASM, so the multi-arch
Alpine images need no native build.

verifyPassword no longer falls back to comparing the password against the
stored hash. That fallback turned every stored hash into a working
credential: anyone with a database dump could authenticate by sending the
hash back. Anything that is not an argon2id PHC string is now refused.

Logins are decided against the database, with the failure counter and the
temporary lockout of PLAN.md section 5.2. An unknown address and a wrong
password give the same answer, and the unknown case still pays for a hash
so response time does not enumerate valid addresses.

Second factor. The TOTP secret is generated server-side, stored encrypted
and never accepted back from the client - the confirm step used to take
whichever secret the caller sent, so anyone could confirm with their own.
Recovery codes are Argon2id, single-use, and consumed under a guard so two
concurrent requests cannot spend the same one. App passwords are issued
and revoked through real endpoints instead of browser state.

Sessions gain a "purpose" claim. Without it the challenge token - handed
out after the password but before the second factor - satisfied every
check a real session did, which skipped MFA entirely.

The dev seed carried a hand-written password_hash whose digest was 24
bytes instead of 32, so it matched no password at all. Nothing noticed
while passwords went unverified; it is a real hash now.

Verified with 30 tests, 13 of them against a real Postgres: wrong password,
unknown account, pass-the-hash, wrong TOTP code, challenge token replay,
lockout, single-use recovery codes, and the surface isolation that F4's
acceptance criteria require.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/dev-seed.sql

@@ -4,14 +4,17 @@ INSERT INTO domains (id, name, punycode_name, is_active)
 VALUES ('00000000-0000-0000-0000-000000000001', 'example.test', 'example.test', true)
 ON CONFLICT (name) DO NOTHING;
 
--- Password: "dev-password-only" hashed with Argon2id - never use in production.
+-- Password: "dev-password-only", a real Argon2id PHC hash - never use in
+-- production. The value here used to be a hand-written placeholder whose
+-- digest was 24 bytes instead of 32, matching no password at all; nothing
+-- caught it while the auth service did not verify passwords.
 INSERT INTO mailboxes (id, domain_id, local_part, email_address, password_hash, is_active)
 VALUES (
     '00000000-0000-0000-0000-000000000002',
     '00000000-0000-0000-0000-000000000001',
     'postmaster',
     'postmaster@example.test',
-    '$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG',
+    '$argon2id$v=19$m=65536,t=3,p=4$uPTQ1A3ZH47pN8AIf2h2dQ$rqu1BtCd9yDUtZQ4oUZlK7djiQlY4heqE6DJUn29lRg',
     true
 )
 ON CONFLICT (domain_id, local_part) DO NOTHING;