[r404r]

Summary

Add email as a delivery channel for inbox notifications. When inbox writes a new
row for a workspace member, an EmailNotifier subscribed to EventInboxNew
renders a subject / text / html pair and dispatches via the existing
EmailService transport chain (SMTP relay → Resend API → DEV stdout).

Today Multica's notification fan-out only writes inbox rows and emits WS pushes;
email is wired for OTP and invitation flows but never reaches end users for
issue activity. This PR closes that gap.

Design notes

• Strictly downstream of inbox. If a user mutes "Comments & Mentions" at the
  inbox layer, no inbox row is written and no email fires. The new
  email_notifications preference is a channel-level kill switch on top of the
  existing per-event groups.
• Async send. The bus subscription callback spawns a goroutine; Publish
  returns immediately, so a slow SMTP host can never block the HTTP request
  that triggered the inbox row.
• Configured gate. Notifier.Register is only called when
  EmailService.Configured() reports a real transport. Without it, the DEV
  stdout fallback would leak recipient + rendered HTML into server logs on
  every inbox row.
• Frontend mirrors BrowserNotificationSetting. Single row under System
  Notifications. When email_configured is false, an "Unavailable" badge +
  hint pointing at SMTP_HOST / RESEND_API_KEY. Otherwise a toggle that
  writes email_notifications into notification_preference.
• Deep links use FRONTEND_ORIGIN, the same convention SendInvitationEmail
  uses. MULTICA_PUBLIC_URL is the API host and would 404 in split self-host
  setups.

What's added

Backend

• server/internal/integrations/email/ — new package (Notifier, Renderer,
  EmailSender interface, types).
• server/cmd/server/email_notifier_adapter.go — bridges *db.Queries onto
  the package-local NotifierQueries interface.
• EmailService.SendNotification(to, subject, text, html) — generic
  entrypoint, same dispatch order as the existing methods.
• EmailService.Configured() — gate for downstream subscribers.
• GET /api/config exposes email_configured: true when SMTP_HOST or
  RESEND_API_KEY is set.
• notification_preference.preferences JSONB accepts a new
  email_notifications key (missing or "all" = deliver; "muted" =
  suppress). No new tables, no migration.

Frontend

• packages/views/settings/components/email-notification-setting.tsx — new
  component mounted in notifications-tab.tsx.
• packages/core/config/index.ts — ConfigState gains emailConfigured;
  populated at boot in auth-initializer.tsx alongside
  workspaceCreationDisabled.
• packages/core/types/notification-preference.ts — NotificationGroupKey
  union extended.
• packages/views/locales/{en,zh-Hans,ja,ko}/settings.json — added
  notifications.email.* keys; parity test enforced.

Out of scope (deferred to phase 2+)

• Email-body i18n by recipient locale (today: English only — EventInboxNew
  doesn't carry user.language).
• Multipart/alternative for SMTP path (today: HTML only; Resend gets both).
• Rate limiting / debounce for @all bursts.
• Retry queue / dead letter handling.
• Inbound email (replies threaded onto issue comments).
• Provider abstraction beyond the existing SMTP/Resend split.

Test plan

• go test ./internal/integrations/email/ — 9 tests pass (Renderer + 5
  Notifier tests including the goroutine decoupling regression and *string
issue_id regression).
• go test ./internal/service/ — EmailService.SendNotification and
  Configured() covered, no existing tests regressed.
• go build ./... clean.
• pnpm vitest run settings/components/email-notification-setting — 5
  tests pass.
• pnpm vitest run parity — locale parity OK (157 tests).
• pnpm typecheck — all packages clean.
• Manual end-to-end (chat-driven, 2026-06-13, dev DB + MailDev SMTP sink
  at localhost:1025):
  • A. DEV mode (no SMTP_HOST, no RESEND_API_KEY) — Settings →
    Notifications shows the "Email notifications" row with "Unavailable"
    badge; no Switch rendered. Server log confirms Notifier did not
    register against the bus (Configured() gate at work).

• B. SMTP configured — /api/config returns email_configured: true; toggle appears, defaults to ON; subtitle changes to
  You'll get an email when there's new inbox activity..

• C. Issue assigned + earlier @mention / new_comment — MailDev
  received [Multica] You were assigned: …, [Multica] You were mentioned: …, and [Multica] New comment: … (multiple
  actionVerb switch branches exercised). POST /api/issues
  returned 201 in 54.4 ms even with downstream SMTP send —
  proves the goroutine decoupling (P1 fix).

• D. Recipient toggle off → no email — Verified
  bidirectionally in one round:
  - dba toggled own email_notifications off; bob (toggle ON) was
  @-mentioned by dba → bob received the email.
  - bob (toggle ON, actor) @-mentioned dba (toggle OFF) → dba
  received the inbox row but no email (MailDev count
  unchanged).
  - POST /api/issues/.../comments returned in 23 ms in this
  round — async path holds under multi-recipient fan-out.
• E. Inbox group muted → no inbox row → no email (the strict
  downstream invariant) — dba turned "Comments & Mentions" off
  AND email_notifications on; bob then @-mentioned dba again.
  Result: no new inbox row for dba, no new email, MailDev
  unchanged. The architecture invariant is observable: when
  notifyMentionedMembers early-returns, EventInboxNew is never
  published and the Notifier is never invoked. POST still
  returned in 25 ms.
• F. Agent task (task_completed / task_failed) — covered by
  unit tests rather than manual run (setting up a daemon runtime
  is out of scope for this verification):
  - actionVerb branches for task_completed / task_failed
  render correctly (TestRender_UnknownNotifTypeFallsBackToGenericSubject
  locks down the switch path).
  - Agent recipients are skipped at the recipient_type filter
  (TestNotifier_SkipsNonMemberRecipients).
• G. No goroutine leak under load — implicit from C/D/E timings:
  10+ POST paths all returned in 23-55 ms with zero email notifier: ERROR/WARN/panic across a ~30-minute session.
  TestNotifier_DoesNotBlockBusPublisher locks the goroutine
  decoupling pattern in CI; an explicit pprof goroutine count
  comparison would require a load-injection step that's not
  warranted at this scope.

Configuration

env	Effect
SMTP_HOST (or RESEND_API_KEY)	Enables the channel. With neither set, the Notifier is not registered.
SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, SMTP_TLS, SMTP_TLS_INSECURE, SMTP_EHLO_NAME, RESEND_FROM_EMAIL	Unchanged — passed through EmailService exactly as before.
FRONTEND_ORIGIN	Base for the "View issue" deep link in the email body. Self-host should already have this set for invitation emails / CORS. Missing → email still ships, just without a link.

Review history

Five codex review passes during development surfaced four real issues, all
fixed before this squash:

1. R1 / P1 — events.Bus.Publish is synchronous, so an inline SMTP send
   would block the originating HTTP request. Fixed by spawning a goroutine in
   the bus callback (regression test
   TestNotifier_DoesNotBlockBusPublisher).
2. R1 / P2 — issue_id arrives as *string (from util.UUIDToPtr in
   inboxItemToResponse), not string; the original assertion silently
   produced "" and emails lost their deep link. Fixed via stringOrPtr
   helper (regression: happy-path test now asserts the deep link).
3. R2 / P2 — Deep links were built from MULTICA_PUBLIC_URL (API host).
   Switched to FRONTEND_ORIGIN to match SendInvitationEmail.
4. R3 / P2 — Notifier was registered even without a configured transport,
   so the DEV stdout fallback printed every notification body into server
   logs on self-host instances that hadn't set up email. Added
   EmailService.Configured() gate.

(There was also an R4 finding about stale Vitest assertions left over from an
earlier i18n edit — fixed in the same branch.)

Final R5 review pass returned clean.

[vercel]

@r404r is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.

[r404r]

Updated onto current main via a merge commit (no force-push). Per @Bohan-J's note in #6486, the conflicts with the mentions/comments split are resolved on this side, and the email toggle now goes through the atomic preference patch (MUL-4798) and the new settings layout.

Delivery hardening from review: only current workspace members are emailed; preference lookups fail closed; links use MULTICA_APP_URL; a bounded queue with sends paced below Resend's default limit (EMAIL_NOTIFICATION_SEND_INTERVAL), with Retry-After-aware retries, so notification bursts can't starve login-code emails.

Known limitation: pacing is per replica. Related demand for multi-channel inbox push: #8152. Happy to move this behind a shared delivery-channel abstraction if you'd prefer.

[r404r]

Updated onto current main again via a merge commit (no force-push).

• Resolved the config/index.ts conflict with the new daemon config fields; this PR only adds emailConfigured.
• Email subjects now have an action verb for every inbox notification type, with a test that fails if a type in inbox.json is missing one.
• The email toggle has an email anchor and is listed in the settings search index.
• Added zh-Hant strings for the email keys so locale parity passes.

Verified locally: DB-backed Go tests (handler, email, service, cmd/server), pnpm typecheck, and vitest (core and views).