Implement JWT Token Refresh Mechanism

Problem Statement

When a user's auth token expires, and they relaunch the app, there is no way to silently restore their session. The current refresh endpoint only accepts a non-expired JWT, so once a token has expired, the app hits a dead end. Without a proper token recovery mechanism, users are forced to manually sign in again — creating unnecessary friction and drop-off at relaunch.
Since the auth token is used in every request and is frequently exposed, extending the auth token’s TTL is not a secure resolution for this issue.

User Story

As a returning app user whose auth token has expired since their last session, I want the app to silently restore my session on launch without prompting me to sign in again, so that I can resume using the app immediately with my subscription state loaded, even if it has been last used long ago.

Definition of Done

• A user object contains both a short-lived access token that cannot be refreshed and a long-lived refresh token.

• The refresh endpoint accepts a non-expired refresh JWT and returns a new short-lived access token along with a new refresh token.

• The authentication endpoint accepts a non-expired auth JWT and returns the requested information/performs the requested function.

• A refresh_ttl window is defined and enforced — tokens outside this window cannot be refreshed and require re-authentication.

• If the auth token is close to expiring, the app uses the stored refresh token to call the refresh endpoint on launch; if successful, the new refresh and auth tokens are stored and the session resumes silently.

• If the refresh fails (token outside refresh_ttl or invalid), the app falls back gracefully to the sign-in screen.

• Subscription state is successfully queried using the new auth token after a silent refresh.

• Changes are documented in the API reference.