Fix: mobile session timeouts (M2-11149, M2-11150)

[sricharan-varanasi]

📝 Description

🔗 Jira Ticket M2-11149

🔗 Jira Ticket M2-11150

Session timeout fixes for mobile browsers, ported from the same fixes on web. Android
pauses background tabs, so a signed-in tab misses its own idle logout and wakes up
acting on stale state.

Changes include:

• A tab checks the shared clock before telling other tabs its session is live, so a
  login-page tab is no longer blocked by a session that has already timed out.
• A login-page tab watches the idle deadline itself instead of waiting to be told, so
  the banner clears on time without a reload.
• A sign-in starts its own idle clock, so a clock left behind by a session that never
  logged out cannot end the new one immediately.
• A tab whose session was replaced leaves for the login page instead of refreshing it
  or keeping itself alive on the new session's clock.
• A tab puts its deadline to the other tabs before logging out. A tab that slept
  through "Stay logged in" used to wake with the old deadline and end the session for
  everyone.

🪤 Peer Testing

Best tested on Android Chrome with two tabs. A shorter VITE_IDLE_TIMEOUT_MIN makes
this practical.

• Sign in on Tab A, leave Tab B on the login page, and stay on Tab B past the idle
  timeout.

  Expected outcome: the yellow banner on Tab B disappears at the deadline.

• Reload Tab B and sign in.

  Expected outcome: sign-in works and stays signed in, with no "automatically
  logged out" banner.

• Switch back to Tab A.

  Expected outcome: Tab A shows the login page with "You signed in with another
  tab or window". Tab B stays signed in.

• With both tabs signed in and the warning showing, tap "Stay logged in" on Tab A,
  wait out the original countdown, then switch to Tab B.

  Expected outcome: both tabs stay signed in.

• Desktop check: sign in on two tabs, then log out from one.

  Expected outcome: the other tab goes to the login page with no "automatically
  logged out" banner.

✏️ Notes

• Same fixes as the web PR, applied to admin's copy of the session code.
• The check for a session that replaced this one relies on the family claim in
  tokens. Confirmed on dev; worth confirming for staging and prod before release.
• Known and not fixed here: an abandoned session is not revoked on the server at the
  deadline, so its refresh token stays valid until it expires. Tracked separately.
• An idle logout now happens 300ms later, which is the window for other tabs to answer.
• No logging was added. These paths are silent by design, and the logout and sign-in
  events they end in are already tracked.

✅ Checklist

Functionality

• The feature behaves correctly in practice and fulfills the intended business purpose
• The implementation accounts for edge cases, avoids subtle logical errors, and handles somewhat rare failure states (e.g. offline mode for mobile, 3rd party being down, etc)

Testing

• Verify there are automated tests added that meaningfully cover critical behavior and failure cases
• Code coverage does not go down as result of this change
• Test suite passes

Security & Data Privacy

• Verify there is no chance we would accidentally log PII to application logs
• Verify this addition does not materially affect our security attack surface, and if so it has undergone security review
• All inputs are sanitized
• New dependencies are well maintained, have significant justification for being added to the project, and are documented in the Curious open source credit page

Logging/Monitoring

• Logging is implemented for this change such that you could troubleshoot this feature in production
• The change/feature is able to be monitored in production

Performance

• This change does not introduce n+1 queries or other performance issues within our expected scale (e.g. missing indexes on frequently queried columns, frequently updating tables that are accessed often)

Readability

• All commented out code is removed
• Debugging code including extraneous log lines are removed
• Code is easy to understand through naming and structure; comments explain intent or non‑obvious decisions

Change Safety

• Backend changes are backwards compatible with old clients, or it is well known they are not and a deployment/rollout plan is in place. This include backend changes being compatible with old mobile app versions, as well as applet versioning within Curious.
• Destructive database migrations are rolled out in stages. For example, renaming a column means adding a new column and migrating the existing data to that columns in one deployment. Then monitoring to ensure that field isn't used, and finally removing that old column in a separate deployment.

[aws-amplify-us-east-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-2266.d2ccder08v9rmu.amplifyapp.com

[adeiji]

Looks good @sricharan-varanasi !