Make the desktop and demo mailbox adapter seam real

[ymcheung]

Problem Statement

The desktop mailbox implementation and demo mailbox implementation do not behave as independent adapters. Desktop calls accept eagerly evaluated demo fallbacks, so operations can execute against demo state before Tauri is invoked. Callers must understand runtime detection, demo mode, and fallback behavior instead of learning one mailbox interface.

Solution

Establish one real mailbox seam with two explicit adapters: a desktop adapter that invokes Tauri and an in-memory demo adapter. Select the adapter once for the active session, remove fallback behavior from the desktop implementation, and make both adapters satisfy the same mailbox interface.

User Stories

1. As a desktop mail user, I want mailbox actions to affect only my desktop mailbox, so that demo state cannot influence real behavior.
2. As a demo user, I want demo actions to remain in memory, so that trying the app cannot invoke native mailbox commands.
3. As a returning user, I want the selected mailbox mode to stay consistent, so that behavior does not change between calls.
4. As a user opening messages, I want reads to use only the active adapter, so that message content is predictable.
5. As a user marking mail read or unread, I want exactly one implementation to process the action, so that state cannot update twice.
6. As a user deleting mail, I want the operation isolated to the selected mailbox, so that destructive behavior cannot leak.
7. As a developer adding a mailbox operation, I want one interface to implement, so that desktop and demo behavior cannot drift silently.
8. As a developer testing mailbox flows, I want to use the demo adapter at the production seam, so that tests exercise caller-visible behavior.
9. As a maintainer, I want environment behavior inside its adapter, so that runtime checks do not spread through callers.
10. As an agent changing mailbox code, I want one explicit seam, so that supported behavior is easy to navigate.

Implementation Decisions

• Retain the existing mail-client seam as the highest testing seam.
• Treat desktop and demo as two real adapters because both provide meaningful behavior.
• Let the desktop adapter own Tauri invocation only; it must not evaluate or mutate demo data.
• Let the demo adapter own in-memory accounts, folders, messages, and mutations.
• Select the adapter once at the session composition point.
• Check both adapters against one shared mailbox interface, including errors and mutation outcomes.
• Keep authentication separate from the mailbox interface.
• Preserve user-visible behavior except for removing cross-adapter side effects.
• Delete the shallow fallback mechanism rather than hiding it behind another abstraction.

Testing Decisions

• Test observable mailbox results through the shared interface, not adapter internals.
• Use the demo adapter as the local-substitutable implementation for interface-level tests.
• Substitute Tauri invocation when testing desktop command names, arguments, results, and errors.
• Prove desktop operations do not change demo message or account state.
• Prove one session uses exactly one adapter.
• Follow the Worker test precedent of injecting external behavior through one seam.

Out of Scope

• Reorganizing frontend mailbox state.
• Implementing provider synchronization.
• Changing the database schema or authentication flow.
• Adding mailbox features.

Further Notes

Complete this before deepening frontend mailbox state because it creates the stable test seam that refactor needs.