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/engagement/channels.js

@@ -44,6 +44,15 @@ const isMode = (value) => MODES.includes(value)
  * @param {string}  def.defaultMode    the mode that applies with no stored row
  * @param {boolean} def.supportsDigest may a preference for this channel be 'digest'
  * @param {string}  [def.description]  one line for the preferences screen
+ * @param {(userId: number) => Promise<{address: string}|null>} [def.addressFor]
+ *        where this channel would send to, or null when it cannot reach the user
+ * @param {(row: object) => Promise<{ok?: boolean, retry?: boolean, transport?: string, detail?: string, addressHash?: string}>}
+ *        [def.deliver] deliver one claimed outbox row. **Must not throw** — the
+ *        worker treats a throw as a transient failure, which is the right guess
+ *        and a worse answer than the channel's own classification. A channel
+ *        without one is declared but not yet deliverable, which is exactly what
+ *        `inapp` is until Phase 7; the worker finishes such a row `failed` and
+ *        says so in the send log rather than pretending it was sent.
  */
 function registerDeliveryChannel(def) {
   if (!def || typeof def !== 'object') throw new Error('registerDeliveryChannel: definition required')
@@ -67,6 +76,16 @@ function registerDeliveryChannel(def) {
   if (defaultMode === 'digest' && !supportsDigest) {
     throw new Error(`registerDeliveryChannel(${id}): defaultMode 'digest' needs supportsDigest`)
   }
+  // Optional, but not optionally-typed. A channel registering `deliver: true` or
+  // a stale import that resolved to undefined would otherwise be a channel that
+  // silently never delivers — the failure Phase 3 deferred the whole behavioural
+  // half to avoid freezing, and the one the worker's "no delivery implementation
+  // yet" branch would report as if it were by design.
+  for (const fn of ['addressFor', 'deliver']) {
+    if (def[fn] !== undefined && typeof def[fn] !== 'function') {
+      throw new Error(`registerDeliveryChannel(${id}): ${fn} must be a function`)
+    }
+  }
 
   channels.set(id, {
     id,
@@ -75,12 +94,22 @@ function registerDeliveryChannel(def) {
     carriesContent,
     defaultMode,
     supportsDigest,
+    addressFor: def.addressFor,
+    deliver: def.deliver,
   })
   return id
 }
 
-/** Every channel, in registration order. The preferences screen's column set. */
-const all = () => [...channels.values()].map((c) => ({ ...c }))
+/**
+ * Every channel, in registration order. The preferences screen's column set.
+ *
+ * **Declarative fields only** — `addressFor` and `deliver` are stripped. This is
+ * what a route serializes, and a function on an object bound for `res.json` is a
+ * key that silently disappears rather than an error; keeping the boundary here
+ * means the API shape is decided in one place instead of by JSON.stringify.
+ */
+const all = () =>
+  [...channels.values()].map(({ addressFor, deliver, ...declared }) => ({ ...declared }))
 
 /** Just the ids. */
 const ids = () => [...channels.keys()]