Adopt stateless PASETO authentication

Decision

Remove the Redis session layer entirely. PASETO tokens become the sole authentication mechanism.

Token structure

{
  "user_id": "uuid",
  "device_id": "uuid",
  "iat": 1234567890,
  "exp": 1234567890  // 90 days from iat
}

No roles or permissions in the token — the database remains authoritative for authorization. Every request fetches current user state from the database.

Authentication flow

On every authenticated request:

1. Validate PASETO token (decrypt with any available key)
2. Check token expiry (exp > now())
3. Validate device binding (token.device_id == X-Device-ID header)
4. Fetch user from database
5. If token is >24h old or key is deprecated → issue new token via X-New-Token response header

Device binding

iOS generates a stable UUID on first launch, stored in Keychain (survives reinstalls). Every request includes X-Device-ID header. Stolen tokens can't be used on a different device. This follows the sender-constrained token pattern from OAuth 2.0 DPoP (RFC 9449).

Session duration

90-day token expiry with sliding window — tokens refresh automatically during active usage (ADR-0027), so active users never experience unexpected logouts. Only users completely inactive for 90 days re-authenticate.

90 days aligns with the upper end of industry standard refresh token lifetimes. Mobile sessions are longer-lived than web sessions — interactions are sporadic and drawn out — but a stateless token without server-side revocation shouldn't extend beyond what's defensible without that infrastructure. Device binding (above) mitigates the primary risk of token theft.

Consequences

Eliminates the entire category of session/token race conditions. Authentication becomes a straightforward token parse, expiry check, and database lookup (~20 lines of middleware). No session cycling, no cookie handling, no Redis session management.

The trade-offs: no immediate token revocation without additional infrastructure (user-level revocation via database flags can be added later), and each request requires a database user lookup instead of a cached Redis session. Web client support would require reintroducing session management, but session-based code can be recovered from git history if needed.