Document fast login and passkey live-validation recipe

[shaun0927]

#747 Document fast login and passkey live-validation recipe

Why OpenSafari should reflect this

SimpleWebAuthn/Auth.js/passkey ecosystems show that fast login is increasingly passwordless, prompt-heavy, and browser/OS mediated. OpenSafari should not become an auth framework, and existing #699 already tracks secure auth profile persistence. The missing piece is a live-validation recipe for login and passkey prompts using OpenSafari's Safari, native alert, app/webview, and auth-profile tools.

This should be reflected because fast login is critical for mobile QA setup time, but incorrect handling can compromise security or make tests flaky.

Scope / how to implement

• Add a focused login/passkey validation guide or helper that composes existing tools:
  • auth profile save/load/reset,
  • Safari/app URL launch,
  • native alert/prompt detection,
  • app/webview context switching,
  • screenshot/log capture on failure.
• Explicitly document what is out of scope: implementing WebAuthn RP/server logic, storing secrets in repo, or bypassing OS security prompts.
• Cross-link Secure auth profile persistence while preserving login persistence UX #699 to avoid duplicating auth persistence work.

Decisions needed before implementation

1. Which fixture or public demo flow is acceptable for passkey/login validation without storing secrets?
2. Should passkey flows be documented as manual/live-only until a stable simulator fixture exists?
3. What secrets handling contract is required for CI?
4. Which OpenSafari tools form the canonical fast-login recipe?

Success criteria

• Maintainers have a clear merge/post-merge validation checklist for login/passkey automation.
• The recipe reuses existing OpenSafari auth/native/webview tools and does not add auth-framework dependencies.
• Security boundaries are explicit: no committed secrets, no prompt bypassing, no duplicate of Secure auth profile persistence while preserving login persistence UX #699.

Post-merge OpenSafari live validation

• Run the recipe against a non-secret fixture or local test app.
• Verify auth profile persistence shortens a second login without leaking credentials in logs.
• Verify native prompt detection records screenshot/log evidence when a passkey or OS prompt blocks automation.
• Verify profile reset returns the simulator/app to logged-out state.

Ambiguity review

This is intentionally documentation/validation-first unless analysis finds a concrete OpenSafari tool gap. Heavy IAM libraries are out of scope.

Direction and necessity review (2026 OSS comparison)

• Aligned: yes — login/passkey validation is needed for fast QA setup, but should remain a recipe over existing OpenSafari tools.
• Necessary: yes as documentation/validation guidance; not a runtime dependency.
• Minimal first PR: docs recipe and security checklist only; do not duplicate Secure auth profile persistence while preserving login persistence UX #699 auth persistence implementation.

[shaun0927]

Implemented and merged to develop via PRs #748-#751 as scoped for this issue set. Closing because the requested issue/PR validation workflow is complete on the integration branch.