feat(notifications): per-channel preferences and the delivery-channel registry (engagement Phase 3)

`notification_subscriptions` answers one question — which streams a user wants
PUSHED — because that is the only question the shipped Android client can ask.
This adds the general one: which subscribable ids, on which channel, in which
mode. The old table becomes the push projection of the new one and keeps its
exact wire shape, so the shipped APK needs no update and no delivery path is
touched.

What lands:

- `engagement/channels.js` — `registerDeliveryChannel` (ENGAGEMENT.md §3.1), the
  declarative half only: id, label, `carriesContent`, `defaultMode`,
  `supportsDigest`. `addressFor`/`render`/`deliver` wait for Phases 6 and 7, for
  the reason `transports/index.js` deferred this file at all. `coreChannels.js`
  declares push / email / inapp through the subsystem's one door.
- `notification_channel_prefs` + a replay-safe `INSERT IGNORE … SELECT` backfill,
  copying the `announce_jobs → announce_job_legs` precedent.
- `GET · PUT /auth/me/notifications/channels`. The PUT is SPARSE — only the
  `(id, channel)` pairs named are written — deliberately unlike the two whole-set
  PUTs beside it. `off` is a mode rather than an omission, so this endpoint has
  no empty-array case and the kotlinx DTO gotcha cannot arise here.

Three decisions the org lead settled before any code, and one corrects the
phase's own acceptance criterion: push's `defaultMode` is `off`, not `instant`.
The plan borrowed "push is opt-OUT" from `team_notification_prefs`, where no row
does mean notified — but stream subscriptions have never worked that way, so
`instant` would have projected the whole catalog into the legacy GET for every
existing user and switched every toggle on in the shipped app after an upgrade
nobody asked for. A test pins the legacy GET at `{streams:[]}` for a fresh user.

One thing not named by the phase, and it is a G24 consequence rather than scope
creep: a trigger ceilinged at `staff` can never reach a non-staff user, so
offering the toggle would be offering a dead control AND disclosing the event
exists — `uo.cheat.detected` would otherwise appear in every player's screen the
moment Phase 11 declared it. Filtered from the catalog and gated on write. That
gave the `staff` label its first consumer, now written down as
`ceilings.STAFF_CEILING_ROLES` (the admin tier's three, deliberately not
`teamGrants.STAFF_ROLES`, which answers a different question).

15 new tests; swagger, route manifest and guards regenerated. No web or app
surface — those are Phases 7 and 8, where a preference governs something visible.

Refs: docs/website/ENGAGEMENT.md Phase 3, §3.1, §4.5

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

server/src/engagement/channels.js

@@ -0,0 +1,128 @@
+// ── The delivery-channel registry ──────────────────────────────────────────
+//
+// ENGAGEMENT.md §3.1, Phase 3. The other half of the axis `transports/index.js`
+// splits: a **channel** is what kind of sink this is (email, push, in-app), a
+// **transport** is how one channel actually delivers (SMTP, ntfy, FCM). Push has
+// had this shape since before anyone named it — `push_devices.transport` is a
+// transport column on a channel with one implementation.
+//
+// **Only the declarative half registers here today**, and that is the whole of
+// what Phase 3 needs. `addressFor` / `render` / `deliver` arrive with the phases
+// that can exercise them: email in Phase 6, in-app in Phase 7. Declaring a
+// function nothing calls freezes a signature before anything has tried to use
+// it, which is the reason `transports/index.js` deferred this file at all.
+//
+// What forced it into Phase 3 rather than Phase 6: `notification_channel_prefs`
+// stores a mode only when a user has expressed one, so reading a preference
+// means knowing the channel's default — and §3.1 says `defaultMode` is expressed
+// **once**. A constant list beside the prefs model would be that expression in a
+// second place two phases before the registry replaced it.
+//
+// Nothing here touches the database, the network or a user record.
+
+// id → channel definition, in registration order.
+const channels = new Map()
+
+// The three modes a preference can take. `digest` is only offered by a channel
+// that declares `supportsDigest` — push and in-app are instant-only in v1,
+// because a digest of content-free tickles is not a thing you can batch.
+const MODES = ['off', 'instant', 'digest']
+
+const isMode = (value) => MODES.includes(value)
+
+/**
+ * Register a delivery channel.
+ *
+ * Validate-then-commit, the same discipline `registerMailTransport` and
+ * `modules/registries.js` use: every check runs before the map is touched, so a
+ * rejected registration leaves nothing behind.
+ *
+ * @param {object} def
+ * @param {string}  def.id             'email' | 'push' | 'inapp' | later 'discord.dm'
+ * @param {string}  def.label          operator/user-facing name
+ * @param {boolean} def.carriesContent false for push — the tickle invariant, stated structurally
+ * @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
+ */
+function registerDeliveryChannel(def) {
+  if (!def || typeof def !== 'object') throw new Error('registerDeliveryChannel: definition required')
+  const { id, label, carriesContent, defaultMode, supportsDigest } = def
+  if (typeof id !== 'string' || !/^[a-z][a-z0-9_.-]*$/.test(id)) {
+    throw new Error(`registerDeliveryChannel: invalid id ${JSON.stringify(id)}`)
+  }
+  if (channels.has(id)) throw new Error(`registerDeliveryChannel: ${id} is already registered`)
+  if (typeof label !== 'string' || !label) throw new Error(`registerDeliveryChannel(${id}): label required`)
+  if (typeof carriesContent !== 'boolean') {
+    throw new Error(`registerDeliveryChannel(${id}): carriesContent must be declared explicitly`)
+  }
+  if (!isMode(defaultMode)) {
+    throw new Error(`registerDeliveryChannel(${id}): defaultMode must be one of ${MODES.join(', ')}`)
+  }
+  if (typeof supportsDigest !== 'boolean') {
+    throw new Error(`registerDeliveryChannel(${id}): supportsDigest must be declared explicitly`)
+  }
+  // A channel that cannot batch cannot default to batching. Cheap to check, and
+  // the failure it prevents is a stored 'digest' row no delivery path can honour.
+  if (defaultMode === 'digest' && !supportsDigest) {
+    throw new Error(`registerDeliveryChannel(${id}): defaultMode 'digest' needs supportsDigest`)
+  }
+
+  channels.set(id, {
+    id,
+    label,
+    description: def.description || null,
+    carriesContent,
+    defaultMode,
+    supportsDigest,
+  })
+  return id
+}
+
+/** Every channel, in registration order. The preferences screen's column set. */
+const all = () => [...channels.values()].map((c) => ({ ...c }))
+
+/** Just the ids. */
+const ids = () => [...channels.keys()]
+
+/** One channel, or null. Callers must handle null: a stored pref row can name a
+ *  channel that is no longer registered, and that must read as "off", not throw. */
+const get = (id) => {
+  const c = channels.get(id)
+  return c ? { ...c } : null
+}
+
+const has = (id) => channels.has(id)
+
+/** The mode that applies when the user has expressed nothing. An unregistered
+ *  channel is 'off' — never on by accident. */
+const defaultMode = (id) => (channels.get(id) || {}).defaultMode || 'off'
+
+/** Which modes this channel will accept from a client. */
+const modesFor = (id) => {
+  const c = channels.get(id)
+  if (!c) return []
+  return c.supportsDigest ? MODES.slice() : MODES.filter((m) => m !== 'digest')
+}
+
+/** Is `mode` a mode this channel accepts? The gate on every preference write. */
+const acceptsMode = (id, mode) => modesFor(id).includes(mode)
+
+// Test-only: the registry is module-level state.
+function _reset() {
+  channels.clear()
+}
+
+module.exports = {
+  MODES,
+  isMode,
+  registerDeliveryChannel,
+  all,
+  ids,
+  get,
+  has,
+  defaultMode,
+  modesFor,
+  acceptsMode,
+  _reset,
+}

server/src/engagement/coreChannels.js

@@ -0,0 +1,74 @@
+// ── Core's own delivery channels ───────────────────────────────────────────
+//
+// ENGAGEMENT.md §3.1 / Phase 3. All three are core's, and none of them is a game
+// concept: a mailbox, a push endpoint and an inbox row are the same three things
+// on any shard running this platform.
+//
+// **They are declared here before two of them can deliver anything**, and that is
+// deliberate rather than premature. A preference is a durable user statement; the
+// three columns of the preferences screen have to exist from the moment the table
+// does, or the first person to open it after Phase 6 finds an email toggle that
+// has never had a value and a screen that changed shape under them. Registering
+// the metadata early costs nothing — the registry holds no behaviour yet — while
+// registering it late means back-filling opinions users were never asked for.
+//
+// The `defaultMode`s below are the whole of G9: "per-channel defaults differ and
+// there is nowhere to express that generically". This is that place.
+
+const { registerDeliveryChannel } = require('./channels')
+
+const CHANNELS = [
+  {
+    id: 'push',
+    label: 'Push',
+    description: 'A silent tickle to your phone; the app then pulls the real content.',
+    // The tickle invariant (docs/android/PLAN.md §11), stated structurally rather
+    // than as a comment: what leaves the server on this channel is { stream, ref }
+    // and never a message body. Phase 7's `deliver` reads this flag; declaring it
+    // false here is what makes "push must not carry content" a property of the
+    // registration instead of a rule each caller has to remember.
+    carriesContent: false,
+    // **Opt-IN, and this is the one place the phase's own acceptance line was
+    // wrong.** ENGAGEMENT.md Phase 3 said a fresh user's push defaults to
+    // 'instant'; §3.1 called push "opt-OUT", borrowing the semantics of
+    // `team_notification_prefs` (where no row does mean notified). But push
+    // STREAM subscriptions have never worked that way: `notification_subscriptions`
+    // holds a row only when a user opted in, so no row means not subscribed.
+    // Defaulting to 'instant' here would have projected the entire catalog into
+    // `GET /auth/me/notifications/subscriptions` for every existing user, and the
+    // shipped Android client would have shown every toggle switched on after an
+    // upgrade nobody asked for. Settled by the org lead 2026-08-29: 'off'.
+    defaultMode: 'off',
+    // A batched tickle is a contradiction — the content is not in the message, so
+    // there is nothing to roll up. Ten events are ten wakeups or one; either way
+    // the app pulls the same inbox.
+    supportsDigest: false,
+  },
+  {
+    id: 'email',
+    label: 'Email',
+    description: 'A message to your verified address.',
+    carriesContent: true,
+    // Opt-IN, per §7.1 Q1: standard marketing-email practice, and the posture
+    // `team_notification_prefs.email_mode` already takes ('off' by default).
+    defaultMode: 'off',
+    supportsDigest: true,
+  },
+  {
+    id: 'inapp',
+    label: 'On the site',
+    description: 'An item in your notification inbox on the website and in the app.',
+    carriesContent: true,
+    // Opt-IN like the other two, and for a reason particular to this channel: the
+    // inbox does not exist until Phase 7. A default of 'instant' would mean every
+    // user is opted into a surface that has no rows and no screen, and the first
+    // thing Phase 7 shipped would be a backlog. Whether the inbox is opt-out once
+    // it is real is a Phase 7 decision with a live surface to look at.
+    defaultMode: 'off',
+    supportsDigest: false,
+  },
+]
+
+for (const channel of CHANNELS) registerDeliveryChannel(channel)
+
+module.exports = { CHANNELS }

server/src/engagement/index.js

@@ -1,8 +1,11 @@
 // ── The engagement subsystem — one door ────────────────────────────────────
 //
-// ENGAGEMENT.md Phase 1. Today this is the mail transport registry and core's
-// own transports; the trigger registry, the rules engine and the delivery
-// channels arrive in later phases and hang here too.
+// ENGAGEMENT.md Phases 1 and 3. Today this is the mail transport registry, core's
+// own transports, and the delivery-channel registry with core's three channels;
+// the rules engine and the render/deliver half of a channel arrive in later
+// phases and hang here too. (The trigger registry lives in `modules/registries.js`
+// instead, because a trigger is something a MODULE declares and modules only ever
+// see one registration door.)
 //
 // **Core's transports register through the same door a module's would**, and
 // they register HERE rather than at the bottom of the registry file. That keeps
@@ -11,12 +14,14 @@
 // `modules/registries.js` (MODULE_API.md §7.6) — and it means requiring the
 // registry never has the side effect of populating it.
 //
-// Requiring this module is what makes `smtp` available. Everything that resolves
-// a transport goes through here, so there is exactly one place a transport can
-// come into existence.
+// Requiring this module is what makes `smtp` and the three channels available.
+// Everything that resolves either goes through here, so there is exactly one
+// place a transport or a channel can come into existence.
 
 require('./transports/smtp')
+require('./coreChannels')
 
 const transports = require('./transports')
+const channels = require('./channels')
 
-module.exports = { transports }
+module.exports = { transports, channels }

server/src/engagement/transports/index.js

@@ -2,9 +2,12 @@
 //
 // ENGAGEMENT.md §3.1, Phase 1. A **channel** is what kind of sink this is (email,
 // push, in-app); a **transport** is how one channel actually delivers. This file
-// is the second half only. The channel registry arrives with the engine that
-// consumes it — registering a channel nothing calls would be a shape frozen
-// before anything had tried to use it.
+// is the second half only; the channel half is `../channels.js`, which Phase 3
+// added when `notification_channel_prefs` needed a single place for `defaultMode`
+// to live. Its render/deliver functions are still deferred to the phases that can
+// exercise them, for the reason this comment used to give about the whole file:
+// registering a function nothing calls freezes a signature before anything has
+// tried to use it.
 //
 // What this replaces: `mailer.buildTransport()` had Gmail's host, port and
 // OAuth2 auth type as literals, so "which provider" was a code edit. Now the