feat(engagement): the email channel on the engine, and the Teams migration (engagement Phase 6)

Email becomes a DeliveryChannel driven by rules, and the Team pipeline stops being
its own thing. `teamNotify.forumPost` now emits an event; a rule decides who is
mailed, through which template, and how often at most. One walk goes forum write
-> events.emit -> rule -> outbox -> worker -> email channel -> template -> SMTP.

Seven decisions settled by the org lead before any code:

  - email only moves; the push tickle and the Discord bridge stay direct calls
  - the EVENT carries its access-checked audience, and `members` resolves to it
  - the four Team rules are seeded DISABLED, with an admin banner and a note
  - team_notification_prefs stays, read by the engine as a scoped preference
  - the payload wins and a structural projection fills the gaps
  - the digest keeps computing at send time; only its state generalizes
  - an unsubscribe token turns off the channel it names, and nothing else

Three defects found while building it:

  - `email.button` never absolutized its href, while image and itemList both
    did. Every rule-driven CTA would have been a dead relative link, because a
    trigger's url variables are validated site-relative by construction.
  - Phase 4a enqueued digest-mode recipients for a drain that Phase 6 decided
    not to build. An outbox row snapshots the payload and so has none of the
    three properties the digest design exists for, including the security one.
  - the digest's send-log row carried no address_hash while the instant row
    beside it did, which would have made half the mail uncorrelatable in Phase 9.

Also: engagement_digest_state + a replay-safe backfill, engagement_outbox.scope_key,
a v2 unsubscribe token that still verifies v1 forever, and the canonical
/public/engagement/unsubscribe pair with the old /public/teams path kept
permanently — mail is not editable once sent.

Verified with 1464 server tests, 324 client tests, and a live rig (MariaDB +
Mailpit + a real Team) covering the instant mail, the digest, the generic
template, a pre-migration unsubscribe link and the backfill's replay-safety.

Docs: RunicGateway/docs#TBD

Co-Authored-By: Claude <noreply@anthropic.com>

server/src/model/engagement/engagementRecipients.db.js

@@ -122,4 +122,29 @@ const storedModes = async (userIds, streamId, channel) => {
   return new Map(rows.map((r) => [Number(r.user_id), r.mode]))
 }
 
-module.exports = { active, staff, subscribers, filterActive, storedModes, MAX_AUDIENCE }
+/**
+ * One user's mailable address, or null — the email channel's `addressFor`
+ * (Phase 6).
+ *
+ * `status = 'active'` is re-checked here even though every audience query already
+ * filtered on it, and the gap it closes is real rather than theoretical: an
+ * outbox row can sit through a `delay_seconds` grace window, so a user banned
+ * between the emit and the send is exactly the case this catches. The cost is one
+ * primary-key lookup on a path that is about to open an SMTP conversation.
+ *
+ * **It does not gate on `email_verified`.** Whether an unverified address may
+ * receive opt-in mail is §7.1 Q1's narrower half, and it is a Phase 9 decision
+ * with the suppression list in front of it; deciding it here by accident would
+ * mean every deployment that upgraded before verifying its users stopped mailing
+ * them.
+ */
+const addressFor = async (userId) => {
+  const rows = await query(
+    `SELECT email FROM users
+      WHERE id = ? AND status = 'active' AND email IS NOT NULL AND email <> ''`,
+    [Number(userId)],
+  )
+  return rows.length ? { address: rows[0].email } : null
+}
+
+module.exports = { active, staff, subscribers, filterActive, storedModes, addressFor, MAX_AUDIENCE }