Complete verification links and preserve verified login email (#60)

docs/ux/auth-journeys.md

@@ -214,3 +214,45 @@ This verifies the browser metadata, not Safari's credential popup. With Flutter
 web accessibility semantics enabled, unfocused semantic inputs initially use
 framework-default autocomplete values until focused; password-manager behavior
 with assistive technology still requires a native browser audit.
+
+## Verification links and login handoff
+
+Task: [#60](https://git.sendico.io/tech/sxchnge/issues/60), branch
+`email-verification-60`. Email links use `/verify-email?token=…`; the web entry
+point installs Flutter's path URL strategy before initializing the application.
+This matches Caddy's existing SPA fallback and preserves the path and query on a
+fresh page load. Previously the default hash strategy could start at login and
+never submit the activation token. Unknown routes retain the canonical login
+fallback; invalid, expired and failed confirmation attempts remain on the
+verification page with the existing recovery actions.
+
+Activation consumes the token, checks the pending account and accepted signup
+facts, and activates the account in the existing database transaction. Only
+after a successful commit does the API return `{verified: true, email: ...}`.
+Failure responses do not disclose the account email. Responses retain the
+shared no-store policy. The frontend backend DTO and mapper produce a
+`VerificationResult`; the verification provider exposes that result only in the
+verified state and clears it on reset, loading and failure. A verified response
+from an older backend without the optional email can still show success.
+
+Success stays visible until the user chooses **Continue to login**. This replaces
+the misleading workspace action that could redirect an unauthenticated visitor
+back to login. The verified email travels through transient router extras into
+the editable login controller; the password starts empty and receives focus.
+Normal password and second-factor checks remain required. The email is not
+added to URLs, serialized history, persistent storage or analytics. A link opened
+in another tab or device can receive the verified address from the API without
+depending on the originating signup form's memory.
+
+Existing requested/succeeded/failed email-confirmation journey signals remain
+the measurement source. Success continues to mean that the confirmation service
+returned a verified result, with simulated outcomes kept separate. No field or
+prefill event is needed. Existing limits around pre-submit abandonment,
+cross-device journey correlation and the in-memory analytics sink still apply.
+
+Regression coverage includes transactional activation and rollback, returned
+email and failure privacy, used-token rejection, backend response mapping,
+provider identity clearing, EN/RU success-to-login navigation, editable prefill,
+empty focused password, and exclusion of email from serialized navigation state.
+The supplied private diagnostic token is not a test fixture or documentation
+input; it is kept out of repository sources and tracker records.