Login/SignUp/CreateProfile drove navigation off a raw `success: Boolean` (and
`googleSuccess`) in a LaunchedEffect with no reset — the C-NAV-002 re-fire shape.
Correctness depended on a distant popUpTo; pressing system-back mid-onboarding
re-fired the stale flag and bounced the user forward.
The fix UNIFIES rather than fragments. Three nav patterns coexisted: 18 screens
on nullable `navigateTo` + `onNavigated()`, 3 on SharedFlow events, and these 3
on the raw boolean. Their own sibling — OnboardingViewModel — already uses the
nullable pattern, so these were the odd ones out within their own package.
Converted them to it: `navigateTo: String?` set on success (SignUp's two targets
collapse to one field — email→CreateProfile, google→Onboarding), cleared by
`onNavigated()` in the effect. Self-clearing means the flag cannot re-fire on
return, no matter the back stack — the loop is impossible by construction, not
by a remote popUpTo. Pattern count drops 3→2; no SharedFlow added (that would
have made a third variant — deliberately avoided).
Error handling unchanged and already unified: `uiState.error` + the house
snackbar (LaunchedEffect(state.error)). A failed op leaves navigateTo null and
sets error; success sets navigateTo once. The bare boolean never modeled the
failure path; this does.
Also deleted a stale exploration reference — `HomeViewModel.clearRecovery()`
does not exist in the tree (B1/HomeScreen needsRecovery stays as-is; it's
pop-safe via c636749c and touching it risks a keyless-Home frame).
Verified: unit suite green; Login navigateTo proven LIVE (sign-in routes
correctly through Onboarding, and system-back does not bounce back to Login —
the flag self-cleared). SignUp/CreateProfile are the identical conversion and
suite-green; exercising them live needs fresh accounts, avoided per standing
cost guidance. A Detekt rule enforcing the two blessed idioms comes in Tier 2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
e02b6a9c9a