User-scope cached billing token to prevent checkout under stale auth subject

[AnthonyRonning]

Summary

Maple caches the billing service third-party JWT in sessionStorage as maple_billing_token. That token is Maple/billing-server state, not OpenSecret SDK state, so the OpenSecret SDK should not know about it or clear it. Maple needs to clear or scope this token whenever the current OpenSecret user identity changes.

Right now the token is stored under a single unscoped key and reused until the billing API rejects it. If the OpenSecret auth identity changes while a still-valid billing token remains in the tab, billing calls can be authorized as the previous user while the UI reads email/profile state from the current user.

Suspected ordering

A plausible ordering that can produce incorrect checkout ownership:

1. A browser tab has a valid cached maple_billing_token for User A.
2. The OpenSecret auth tokens in localStorage change to User B through login/OAuth/deep-link/native auth or another auth transition.
3. The cached billing token remains in sessionStorage because it is not tied to the OpenSecret user id.
4. The pricing page builds checkout request data from current UI auth state for User B.
5. BillingService reuses the stale billing JWT for User A.
6. Billing server keys checkout/customer creation by the JWT subject, so checkout is created under User A while request body fields came from User B.

This is especially risky around selected-plan auto-checkout flows because checkout can be triggered immediately after auth/navigation.

Code paths to audit

• frontend/src/billing/billingService.ts stores maple_billing_token as one global sessionStorage key and reuses it until rejected.
• frontend/src/components/DeepLinkHandler.tsx writes new OpenSecret auth tokens and reloads without clearing Maple billing state.
• Some signout paths call os.signOut() directly. Since the OpenSecret SDK should not know about Maple billing state, those Maple UI paths should clear billing state themselves before/after signout.
• /login and /signup already-logged-in redirect effects can navigate to /pricing?selected_plan=... without clearing or validating the cached billing token for the current user.
• Billing React Query keys such as ["billingStatus"] are not scoped by current user id.

Expected behavior

Maple should guarantee that billing requests use a billing JWT for the current OpenSecret user, or generate a fresh one before making the request.

Suggested fix

• Make billing token ownership explicit in Maple, not the OpenSecret SDK.
• Clear maple_billing_token whenever os.auth.user?.user.id changes or auth becomes logged out.
• Consider storing the billing token under a user-scoped key, or decode/check the token sub before reuse.
• Clear billing token in Maple-owned auth transition paths, including deep-link/native auth and signout UI paths.
• Scope billing query keys by user id, for example ["billingStatus", userId].
• Prevent selected-plan auto-checkout from running until billing token state has been validated/refreshed for the current user.

No customer identifiers or production-specific data are included here because this repo is public.

[AnthonyRonning]

Follow-up from validating CodeRabbit feedback on PR #607:

This is confirmed as the same pre-existing issue, not an Agent Mode regression.

History and current trigger

• The single unscoped maple_billing_token cache in frontend/src/billing/billingService.ts dates back to the initial Maple commit (a8df346c, January 2025).
• Bug: Lingering third party billing token #127 added clearing calls to common login/signup/OAuth flows, which mitigated several paths but did not make token ownership explicit.
• The current master version of frontend/src/components/DeepLinkHandler.tsx still replaces OpenSecret access/refresh tokens and reloads without clearing the billing token. sessionStorage survives that same-WebView reload.
• TeamSeatMismatchAlert is mounted globally and queries billing/team state as soon as a user is authenticated, so master can already consume a still-valid previous-account token without waiting for checkout.
• A valid old token does not produce a 401, so executeWithToken never reaches its regenerate-on-auth-error path. The third-party JWT is account-bearing via sub and currently lives for about one hour.

PR #607 touched adjacent billing lifecycle code by refreshing the singleton's OpenSecret context and adding another sidebar billing-status query. That made the invariant visible to CodeRabbit, but it did not introduce the unscoped token or deep-link path. This should remain a separate fix for this issue.

Recommended robust fix

Rather than adding more clearing calls alone:

1. Store an owned record such as { userId, token } instead of a raw token.
2. On every token read, require the current verified os.auth.user?.user.id to match the stored owner. Delete mismatched, signed-out, malformed, and legacy raw values.
3. Clear the record when updateOpenSecret observes an identity change or logout, while preserving it for same-user context refreshes.
4. When generating a token asynchronously, capture the initiating user ID and re-check it after generation before storing or using the token. An A-generation that resolves after switching to B must not repopulate the cache.
5. Scope billing-related React Query keys by user ID, or explicitly invalidate/remove the prior account's billing queries during transition.
6. Keep explicit clearing in Maple-owned deep-link/native-auth and logout paths as defense in depth.

Focused tests

• same-user context refresh preserves and reuses its owned token;
• A → B discards A and generates/uses B;
• legacy raw/unowned values become cache misses;
• signed-out context cannot use a stored token;
• token generation started for A cannot store or execute after switching to B;
• deep-link auth transition cannot expose A's billing/team/credit/portal state under B.

This keeps the fix in Maple, where the billing token is owned, without coupling the OpenSecret SDK to Maple-specific billing state.