Unify Inbox arrival notifications behind device and Send email preferences

v2.1.0 reconciliation — 20 September 2026

Partial fix shipped in #1840: Assistant compose uses the web reply queue instead of generating mail, suppresses notifications from the owner's own local sender address, and normalises participant aliases. This does not establish the unified durable notification pipeline described below.

Remaining verification must cover:

• One assistant request: no notification for the owner's submission, one eligible incoming notification for the answer, and an open conversation updates without refresh.
• Retry, reconnect and restart: no duplicate notification.
• Historical IMAP bridge records newly receiving UIDs: distinguish backfill from genuinely new arrival; do not bulk-change users' read state as a workaround.
• Two owners, disabled email, revoked devices and actively viewed conversations.

Keep open. No authenticated end-to-end notification or restart verification was performed for this reconciliation.

Desired user model: when a new incoming item reaches Inbox, notify the owner on their enabled devices and optionally send email to the verified address. One Notifications settings section; no separate mail-forwarding concept in the final experience.

Current gap: mail forwarding subscribes to MailReceived; push subscribes to mail/reminder/operator events. New web, XMPP and other thread updates are not uniformly covered. The settings cleanup names the destination and truthfully limits Send email to mail until this backend work is complete.

• Define one persisted incoming-Inbox event after successful storage, with account/thread/message identity and origin; do not notify for the owner's own sent message.
• Route all relevant clients and assistant/background results through it, without duplicate notification from existing MailReceived hooks.
• Preserve replies/threading for mail and prevent notification-email ingestion loops.
• Respect verified destination, email opt-out/unsubscribe and per-device subscription settings; choose a clear policy for already-read/actively viewed conversations.
• Use durable delivery status and idempotent retries, bounded attempts and no model calls merely to generate notifications.
• Keep existing preferences effective during migration and account deletion cleanup complete.
• Validate with two accounts and a restart: exactly the intended account receives each enabled notification; disabled email remains off; no repeated notices after retry.

Once complete, simplify UI copy to Send email to [verified address], with no transport-specific explanation. Part of assistant reliability checklist #1804.

Start by reviewing the partial fix in #1840 and the assistant reliability checklist in #1804, then trace the existing MailReceived and push notification paths described here. Done means durable, idempotent Inbox notifications satisfy the listed two-account, retry, restart, preference, threading, and read-state checks without duplicates or ingestion loops.