Use an independent browser database per signed-in user

Problem

Stormbox currently uses one origin-scoped browser SQLite database. Logging out clears Pinia/in-memory state but retains the database. If different users sign into the same Stormbox origin sequentially in one browser profile, the next login can connect to cache rows created under the previous login.

This is strictly a client-side browser-storage isolation problem. It does not alter which JMAP accounts or shares the server exposes.

Expected architecture

Each authenticated principal must open a separate, independent SQLite database. Do not add user/profile partition keys throughout the existing schema.

Derive the database identifier deterministically from:

• the server origin; and
• a stable authenticated principal identifier (OIDC sub preferred; authenticated username fallback for non-OIDC connections).

Use an opaque hash rather than placing the raw identity in the database name.

The existing accounts table continues to represent JMAP account scopes inside that user's database, including personal and shared accounts.

Lifecycle

• Resolve the authenticated principal before selecting/opening the mail database.
• The SharedWorker/repository connects only to that principal's database.
• Logout stops sync, detaches ports/state, and closes the active database connection.
• A subsequent different login opens a different database.
• Returning to the same principal reopens that principal's existing cache.
• Revoked shared accounts are reconciled against the current JMAP Session within that user's database.

Migration considerations

Define an explicit policy for the existing fixed-name database:

• migrate it once when its owner can be identified safely; or
• discard it and rebuild from the server if ownership is ambiguous.

The server remains authoritative, so rebuilding is preferable to risking cross-user cache attribution.

Acceptance criteria

• Two sequential users on the same web origin connect to different physical IndexedDB/SQLite databases.
• Neither user can query the other's cached accounts, folders, messages, bodies, rights, subscriptions, or favorites.
• The same user reconnects to the same database across reloads/logins.
• OIDC email/name changes do not change database identity when sub is stable.
• Basic-auth/self-hosted users receive a stable server-origin + username database identity.
• Worker and repository lifecycle tests prove the previous database is closed before switching principals.
• Browser tests cover two sequential logins without private browsing or separate browser profiles.

Start by tracing how the SharedWorker and repository resolve authentication state, open the current fixed-name browser database, and handle logout. Define the principal identity and migration behavior there, then use the worker/repository lifecycle tests and browser tests to verify database separation, safe switching, same-user reuse, and closure before a new login.