Fix authentication request mismatch: double-tap guard + stale redirect drop

[wparad]

Summary

Follow-up to #8 (merged) — the diagnostic logging it added surfaced a real "authentication request mismatch" happening in practice, root-caused here.

Two distinct triggers, both fixed:

• Double-tap on Continue. Compose doesn't debounce onClick, so two rapid taps could fire authenticate() twice before the first tap's status update recomposed the button away. The second call's POST /authentication overwrites the pending request the first call's Custom Tab is about to redirect back to → mismatch. LoginScreen now disables Continue synchronously on click via a local guard (signInStarting), independent of the coroutine's async state update, so a second tap in the same frame is a no-op.
• "Try again" while an old Custom Tab is still alive. This is a legitimate, intentional retry path (shown after the slow-hint), but the abandoned tab can still redirect back afterward carrying its now-superseded authenticationRequestId. authenticate() already logged this abandonment; completeAuthenticationRequest() now checks the redirect's ID against the recorded abandoned one and drops a recognized stale redirect quietly (info log, no _authStatus mutation, no user-facing error) instead of throwing AuthressException("Authentication request mismatch"). A mismatch that isn't a recognized abandonment still throws — that's still a real problem worth surfacing.

Test plan

• Manual: rapid double-tap Continue — confirm only one Custom Tab opens and no mismatch error appears
• Manual: tap Continue, wait past the slow-hint, tap "Try again", then complete sign-in in the first browser tab if it's still open — confirm the stale redirect is dropped silently (visible only as an info log in the diagnostic overlay) and the second attempt still completes normally
• Could not run a full Gradle build in this environment (no Android SDK available in the sandbox); changes were reviewed manually against existing call sites

---

Generated by Claude Code