Fix post-login redirect when the session cookie is off-origin

Signing in showed the "Welcome back!" toast but never left /login. The
session cookie was host-only on the API subdomain, so the Next middleware
guard on the site origin saw no cookie and bounced /dashboard straight
back to /login?redirect=/dashboard.

- Add AUTH_COOKIE_DOMAIN, wiring Better Auth's crossSubDomainCookies so
  the cookie also reaches the site origin. Unset in dev, where localhost
  is single-host and must stay host-only.
- Navigate after authentication with a full page load, via a shared
  authRedirect helper: only a top-level request carries the httpOnly
  cookie. Used by the login, register, magic-link and Google flows.
- Show "Redirecting..." on the login and register pages and keep the
  submit button disabled until the browser replaces the page, instead of
  re-enabling it mid-navigation.
- Guard against a redirect loop with a sessionStorage marker. A React ref
  cannot do this: the full page load resets component state. If the
  destination bounces back, explain it rather than navigating again.
- Middleware: accept any *.session_token cookie so a cookiePrefix change
  cannot lock everyone out, and preserve the destination's query string.
- Trust any loopback port in dev, so reaching the dev server through a
  forwarded port does not fail Better Auth's CSRF origin check.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

backend/.env.example

@@ -59,6 +59,14 @@ BETTER_AUTH_SECRET=
 # FRONTEND_URL when unset). E.g. https://spanglishcommunity.com
 BETTER_AUTH_URL=
 
+# Session cookie domain, shared across subdomains. Set this when the API is served
+# from a different host than the site (e.g. api.spanglishcommunity.com vs
+# spanglishcommunity.com): without it the cookie is host-only and the frontend's
+# Next middleware cannot see it, so /dashboard and /admin bounce back to /login.
+# Must start with a dot. Leave EMPTY in development (localhost is single-host).
+# E.g. .spanglishcommunity.com
+AUTH_COOKIE_DOMAIN=
+
 # Extra reverse-proxy IP prefixes allowed to set X-Real-IP / X-Forwarded-For
 # (comma-separated, e.g. "172.20."). Loopback and RFC1918 ranges are always
 # trusted; anything else is treated as a client and rate-limited by its