Show accepted signup delivery without a second send step (#62)

docs/ux/auth-journeys.md

@@ -296,3 +296,64 @@ real token was checked read-only and remains unused and unexpired, with its
 account pending verification, ready for the user to reopen the link. PR #61 has
 not been merged into remote main; this local deployment does not imply a main
 branch merge.
+
+### Accepted signup delivery (#62)
+
+Task [#62](https://git.sendico.io/tech/sxchnge/issues/62), branch
+`email-verification-62`. On October 23, signup returned HTTP 202 and the local
+SMTP provider accepted its message with status 250, while the user reported an
+internal-error screen immediately after Create account. No subsequent
+verification request from that attempt reached the BFF. The precise original
+client exception was not captured; an ordinary isolated release reproduction
+succeeded. The regression below deliberately injects an unavailable follow-up
+send service to cover the post-acceptance failure path without claiming that
+injected exception was the original cause.
+
+Backend and preview signup mappers now return a `VerificationDelivery` domain
+receipt with the recipient and simulation status. It means that signup accepted
+the email-queue operation, not inbox delivery, account activation or a session.
+The signup provider exposes it through its operation result. The form captures
+the receipt before clearing password controllers, whose change listeners reset
+auth state, and passes it as transient router extra. The verification provider
+initializes directly in the sent state; mounting the page performs no send.
+This replaces the backend adapter's hidden one-use signup cache. Every explicit
+resend now invokes its service, including the first one after signup.
+
+Routes without a receipt retain their existing behavior: unverified login may
+request an email, a fresh verification page asks for an address, and emailed
+links run confirmation. Recipient changes invalidate the displayed claim until
+another send succeeds. New receipts replace stale recipients. The route codec
+discards the receipt when serializing history, so reloads do not invent a queued
+result or retain the address. No token or password is included in the receipt.
+
+The existing email-delivery requested/succeeded signals now follow the accepted
+signup receipt inside the instrumented service instead of a synthetic send on
+page mount. They stay in the signup journey, occur once for the accepted
+operation, and remain intermediate queue-acceptance signals. Resends retain
+separate attempts and failures; confirmation remains the terminal outcome.
+Simulation and privacy rules are unchanged, including the in-memory analytics
+and cross-device correlation limitations above.
+
+Frontend review covered the complete app/auth contribution and preserved the
+DTO, mapper, service, domain model, provider and UI boundaries. Regressions cover
+accepted signup followed by unavailable resend, explicit retry, normalized
+receipt mapping, provider initialization/reset, recipient replacement, transient
+history, event correlation and exclusion of form values from analytics. EN/RU
+flow tests run at 390px with 1.5x text scaling; existing keyboard, autofill and
+accessibility suites also pass. Changed-file Dart format checks, analysis in
+`frontend/app` and `frontend/packages/sxchnge_auth`, and `make test-frontend`
+(221 tests) pass. The new injected-failure regression failed on the previous
+implementation and passes with the receipt handoff. A release-browser fixture
+with the same backend adapter and a failing resend service shows Check your
+inbox after signup with no send call, then the expected error only after an
+explicit resend. It sends no email. Native Safari was not automated.
+
+The frontend image was rebuilt with freshly resolved stable digest pins and
+recreated without restarting BFF. The served JavaScript matches the new image
+at SHA-256 `0a45ce6f0b4658b1f03d8e39b9e39fd3fbfcf6f1626cb3f17705dce2da130a6c`.
+Normal browser-trust HTTPS serves the frontend and API with HTTP 200.
+`sh infra/local/tools.sh verify` passes all seven services, Vault/database
+checks and authenticated Sendico currency/ledger reads. No new customer email,
+activation or payment was submitted for this change, and no security scan was
+requested or run. The user's pre-existing browser tab must reload to use the
+new bundle; their original Safari exception remains unobserved.