Phase 4 §2 + §1/§4: OnboardingIntent post-OTP routing + test naming + register-screen overflow

Spec §2 (flow_customer.mermaid) routes post-OTP based on user-lookup +
has_transacted, but the implementation previously dumped every OTP
success on /home. Introduce `OnboardingIntent` provider: set to
`onboarding` by routeForVerifChoice's verified branch (the "aku mau
curhat" transaction journey), set to `recover` by SHome1st's masuk →
banner. Router redirect on AuthAuthenticatedData+isAuthRoute consumes it:
`onboarding` → /payment/entry (dispatches S6 paywall vs PickMethod via
first_session_discount.eligible); `recover` → /home. Intent is reset in
/payment/entry's initState so subsequent masuk → flows don't inherit it.

auth_notifier.verifyOtp uses .copyWithPrevious on AsyncError so
valueOrNull retains AuthOtpSentData/AuthAnonymousData through OTP
failures — required for the OTP-blocked recovery path
(/onboarding/anon/method → /payment/method-pick) to clear the global
redirect without bouncing to /home. Router also extends the
isAuthRoute/isOnboardingFlow carve-out to AuthOtpSentData.

Maestro tests adopt `ts-<app>-<NN>-<MM>-<descriptor>.yaml` convention:
NN = mermaid section, MM = sub-flow index. New ts-customer-02-01..05
cover the §2 branches (verified brand-new → S6, existing-no-tx → S6,
existing-tx → method-pick, OTP-blocked → method-pick, anonymous first-
timer → method-pick); deferred 02-06/07/08/09 documented in
README_section_02.md. TS-07 → ts-customer-02-10 (masuk → recovery);
TS-01..06 → ts-customer-04-01..06 (§4 returning-user). Shared
onboarding_new_user_verified.yaml subflow extracted.

Register screen's body Column now uses LayoutBuilder + SingleChildScrollView
+ ConstrainedBox + IntrinsicHeight so the keyboard-open layout no
longer overflows by 1.3 px (verified visually).

Spec prose updated at flow_customer.mermaid §2 to describe the
intent-driven routing + login-vs-transaction divergence.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

requirement/flow_customer.mermaid.md

@@ -130,6 +130,33 @@ flowchart TD
 > first-time pricing off forever. Backend phone-lookup behaviour already
 > exists (see Phase 1 auto-link via phone); the app-side reconciliation +
 > `has_transacted` plumbing is the new work.
+>
+> **Implementation (2026-05-18):** post-OTP routing is driven by an
+> `onboardingIntentProvider` (`client_app/lib/core/auth/onboarding_intent_provider.dart`)
+> that's set to `OnboardingIntent.onboarding` by `routeForVerifChoice`
+> (verified branch in `verif_choice_sheet.dart`) and consumed by the
+> router redirect for `AuthAuthenticatedData` on any auth route. When the
+> intent is `onboarding`, the redirect returns `/payment/entry`; otherwise
+> (default `recover`, set by the masuk → handler) it returns `/home`.
+> `/payment/entry` then dispatches S6 vs PickMethod via the backend's
+> `first_session_discount.eligible` flag — which is computed as
+> "phone-verified AND no prior completed chat_sessions" in
+> `pricing.service.js::isCustomerEligibleForFirstSessionDiscount`. That
+> single check covers both "brand-new" and "existing-but-never-paid"
+> (UserLookup=no and UserLookup=yes+has_transacted=false in the mermaid
+> above).
+>
+> **Login-vs-transaction divergence:** the SHome1st "masuk →" login-recover
+> banner pushes `/auth/register` with intent left at `recover`, so its
+> post-OTP path lands on `/home` (the user expects to see their chat
+> history, not be thrown into payment). This is a deliberate departure
+> from a strict reading of the mermaid arrow, motivated by the user
+> directive that login-intent and transaction-intent entries should not
+> share the same landing zone. Maestro coverage:
+> [client_app/.maestro/flows/ts-customer-02-10-recover_via_masuk_existing_user_to_home.yaml](../client_app/.maestro/flows/ts-customer-02-10-recover_via_masuk_existing_user_to_home.yaml).
+> Tests for the §2 transaction-CTA branches live under
+> `ts-customer-02-01..05`; see
+> [client_app/.maestro/flows/README_section_02.md](../client_app/.maestro/flows/README_section_02.md).
 
 ### 2.1 Anonymous → existing-user merge (post-transaction OTP) 🔴