Implement Kaukus user setup and password email flows

## Outcome Implement Rust-native Kaukus onboarding while preserving the consumed v2 API shapes and existing database/schema/credential compatibility. ## Required behavior - Creating a passwordless human sends no email. - Kaukus direct password update sends a localized password-set notification; changeRequired:false means the password works without another change at login. - invite_code and password_reset email APIs send an expiring single-use link to the same password form, with no visible code field or manual code exchange. - OIDC login must be username-first: the first form asks only for username, then either sends setup email and shows check-email feedback for an active passwordless account or displays a password-only second stage. Users must not be instructed to leave a visible password field empty. Preserve SSO/account selection, explicit change-account navigation, en/nb/da localization and no-JavaScript operation. - Login-originated email setup now resumes the original live OIDC/PKCE request after password creation in the bound browser and for the selected account, returning directly authenticated to the RP. Continuation is signed and issuer/purpose/browser/account-bound; final login reuses the transactional credential/user/policy/request boundary with the exact newly stored hash. Stale requests restart at the server-validated RP origin without authentication. Standalone API, unrelated-account and cross-browser links cannot resume another login and use generic completion feedback. No caller-supplied return URL. Continuation-aware setup CSP permits only the validated RP origin, including after validation errors. - Essential forms work without JavaScript in en/nb/da. No SMS. Old Go invitation links need not work at hard cutover. ## Constraints and acceptance Reuse UserService, login/CSRF/localization, password policy/crypto and transactional projection writes. Keep orchestration independent of HTTP and PostgreSQL. No migrations or mixed writers. Persist email work atomically with credential changes and retry SMTP failures across restarts; never persist/log plaintext credentials or link tokens. Recheck token expiry, single use, recipient/account state and password lifecycle under the stable user lock. Reject stale/replayed/foreign tokens, denied API access, invalid password and CSRF without partial writes. Validate workspace fmt/strict Clippy/tests and opt-in restored-database flow/concurrency/schema checks. Record any unverified delivery/browser/Go restart gates explicitly. ## Implementation and testing boundary The setup/link/delivery implementation passed approved synthetic validation, but the owner clarified that the primary login UX requires a real username-first two-stage form. The new implementation renders username-only first, branches in the application service to email/password, and carries selection in an issuer/request/purpose/expiry-bound signed HttpOnly cookie. Password POST cannot supply/switch username, unknown/inactive accounts use generic password failure, errors/language changes retain the password stage, and explicit account change returns to username/account selection. Existing SSO and final transactional credential/policy checks remain in place. Formatting, strict all-target/all-feature Clippy, 111 default tests and all 45 synthetic database-backed tests pass, including 11 setup/stage tests and unchanged SSO/account selection, real Ruby API contracts and pinned-Go restart. Signed-selector unit coverage rejects wrong issuer/request/purpose, expiry, forged identity and malformed selections; HTTP stage coverage rejects missing/cross-request selection and preserves password stage across locale/CSRF errors. Chrome passes username-only entry, required password-only next stage, all locales, wrong-password retention, explicit account switching, direct check-email branch for passwordless users, actual Mailpit link completion, both RP logins/logout and generic unknown-user failure without email. Browser-wide JS disabling remains unavailable; script-denying CSP/SSR and no-script DOM are verified. The clean fixture is restored and the isolated identity/Mailpit/RP environment restarted for owner testing. Owner approved resetting the synthetic fixture and regenerating credentials. Reset and phase-specific verification are complete; provenance/destination guards stayed enabled throughout. Production-data execution remains prohibited. The username-first and automatic setup-to-RP continuation clarifications are implemented and verified; Implementation is committed as `14a4d3b` (`feature: Add user setup and isolated synthetic fixtures`); the working tree is clean. Private generated credentials, dump/archive and build/runtime state are ignored and were not committed. Current formatting/strict Clippy/default tests pass, and all 49 synthetic database-backed tests pass, including 15 setup/stage/continuation cases, original state/callback verification, expired-request no-auth fallback, unrelated-account/cross-browser denial and existing real-Ruby/Go restart gates. Crypto tests cover browser/issuer/purpose/expiry and safe callback binding. Chrome uses the actual Mailpit link in the same profile and directly completes the original RP login in English and Danish without restarting authorization or reentering credentials; mismatch/short-password errors and language changes preserve continuation, used links cannot replay login, notifications exclude plaintext passwords, and no CSP redirect failures occur. The clean synthetic baseline and isolated owner-testing environment are restored; credentials regenerated in .env.local. Production-data execution remains prohibited. It uses Rust-native setup/email aggregates without schema changes, 256-bit hashed and AES-GCM-sealed link tokens, one-hour single use/lifecycle validation, actual policy requirements in localized forms, and transactional password notifications. Automatic login retries reuse a live link; explicit API resends may replace it after a one-minute cooldown. SMTP uses explicit Rust environment settings, not stored Go provider credentials, and local tests used only a loopback sink. Earlier verification passed formatting, strict workspace Clippy, 104 default tests, nine new disposable-clone setup/SMTP/security/concurrency tests, existing repository/API/admin/OIDC/real-Ruby regressions, and the extended exclusive-writer pinned-Go restart gate including pending Rust setup/email state. Chrome passed en/nb/da setup, validation, mobile layout, PRG/reload, replay rejection and final password login to a loopback callback. Browser-wide JavaScript disabling was unavailable; HTTP tests assert script-denying CSP and no code/token fields. Source and clone schemas stayed unchanged. Changes are uncommitted. ## Current validation and remaining deployment gates Owner approved an entirely synthetic replacement and removal of local restored production databases. The restored cluster and two orphaned identity volumes are removed; dump archive retained. Proper validation now passes on the approved 11-user synthetic baseline: formatting, strict Clippy, 108 default tests, nine setup/SMTP/security/concurrency tests and all 43 synthetic database-backed tests, including the actual Ruby client and pinned-Go restart with pending Rust setup/email state. Chrome follows actual Mailpit links, checks localized policy/validation/mobile layout/PRG/replay/notifications, verifies direct-password readiness, and completes diagnostic RP login/logout/re-authentication inside an egress-denied namespace. No real credentials/providers are used. All test servers are stopped; only the clean synthetic PostgreSQL baseline remains. The testing blocker is resolved. Production-data restores/clones remain prohibited, production serve is restricted by synthetic provenance guards pending explicit cutover approval, and real-provider SMTP configuration/smoke plus production fingerprint/cutover controls remain deployment gates. Changes are uncommitted.