OTP verify screen resets after leaving app to copy code from email

Report (user video)

After requesting an OTP by email in the app, if the user closes/backgrounds the app, opens Mail, copies the code, then returns to the app, the flow resets and asks for email/phone again instead of staying on the code entry step with the same destination address.

Expected

Returning to the app should still show Verify OTP for the same type + value (email/phone) until the user verifies, cancels, or the OTP truly expires — same as staying in-app.

Likely cause (inspector-app)

• login.tsx pushes verify-otp with route params only: { type, value }.
• verify-otp.tsx reads identity only from useLocalSearchParams (value, type).
• On iOS/Android, process death, aggressive memory reclaim, or navigation state restore can drop the stack/params, sending the user back to login or leaving verify with an empty value.

Suggested direction

1. Persist pending OTP context when entering verify (e.g. SecureStore / expo-secure-store or encrypted async storage): type, value, optional timestamp.
2. On verify-otp mount, if params are missing/empty, hydrate from storage; if still nothing, redirect to login.
3. Clear storage on successful verify, explicit “Change email/phone”, or logout.
4. Re-test: background → Mail → copy → resume; force-kill app → relaunch → should recover or fail gracefully with one clear path (not silent reset to login without explanation).

Code refs

• inspector-app/app/(auth)/login.tsx — router.push to /verify-otp with params
• inspector-app/app/(auth)/verify-otp.tsx — useLocalSearchParams for type / value

Acceptance criteria

• [ ] Repro above: user returns to app and can still enter OTP for the same email without re-entering it.
• [ ] Cold start after kill: either restore verify state or show intentional UX (not ambiguous reset).
• [ ] Phone OTP path behaves the same if applicable.