Fix: align access cookie lifetime to refresh cookie (Codex P1 finding)

The auth_cookies module set ACCESS_TOKEN_MAX_AGE to 7 days while
REFRESH_TOKEN_MAX_AGE was 30 days. The docstring on those constants
claims "the access token mirrors [refresh] so a quiet tab doesn't
lose only half its credentials" — but the actual values didn't
mirror.

Real-world failure mode:
  * Session restore (resolve_authenticated_context) requires BOTH
    cookies present.
  * A user returning after 7+ days (but within 30) has a valid
    refresh cookie but a purged access cookie.
  * Restore rejects the half-credentialed pair and forces a fresh
    OAuth re-login, defeating the "stay signed in" UX the 30-day
    refresh window was meant to deliver.

Fix matches the docstring's stated intent: both cookies live for
30 days. The COOKIE's max_age governs browser purge time, NOT the
JWT's validity — Supabase rotates the access JWT on every restore
using the still-valid refresh JWT, so the inside-the-cookie token
being temporally stale is fine and expected.

Codex P1 finding on PR #2 (May 2026). Auth-test suite (14 tests)
still green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: LEANDERANTONY

backend/services/auth_cookies.py

@@ -22,10 +22,21 @@
 REFRESH_TOKEN_COOKIE = "ja_refresh_token"
 
 # Sliding expiries. Refresh token controls "stay signed in" duration; the
-# access token mirrors it so a quiet tab doesn't lose only half its
-# credentials. AuthService rotates tokens on restore, and the router
+# access cookie mirrors it so a quiet tab doesn't lose only half its
+# credentials. AuthService rotates tokens on restore (Supabase mints a
+# fresh access JWT from the still-valid refresh JWT), and the router
 # re-issues both cookies on every restore call.
-_ACCESS_TOKEN_MAX_AGE_SECONDS = 60 * 60 * 24 * 7        # 7 days
+#
+# The COOKIE's max_age controls when the browser purges the cookie;
+# the JWT inside has its own short-lived exp claim (Supabase rotates
+# on restore). Keeping both cookies at the same max_age means a user
+# returning within the refresh window always has both cookies present
+# for the restore call to use — without that, a 7+ day quiet user
+# would lose their access cookie while the refresh cookie is still
+# valid and `resolve_authenticated_context` would reject the
+# half-credentialed restore, forcing an unnecessary re-login (Codex
+# P1 finding on PR #2, May 2026).
+_ACCESS_TOKEN_MAX_AGE_SECONDS = 60 * 60 * 24 * 30       # 30 days
 _REFRESH_TOKEN_MAX_AGE_SECONDS = 60 * 60 * 24 * 30      # 30 days