feat(engagement): the in-app channel, core and web (engagement Phase 7)

ENGAGEMENT.md Phase 7. `user_notifications`, the in-app DeliveryChannel, the
four inbox routes, and the web surface — plus the two pieces earlier phases
assigned here that Phase 7's own acceptance line omits.

Four decisions settled by the org lead before any code:

1. `inapp` defaults to `instant` — the only channel that does. Push wakes a
   device somebody is holding and email leaves the building, so both are asked
   for; an inbox item is a row on a page the user chose to open. Left `off` the
   channel ships dead.
2. The phase takes push's `deliver` (§2603) and the web per-channel preferences
   screen (Phase 3's as-built), neither of which its own bullets mention.
3. The inbox takes `/auth/me/notifications` and `/account/notifications`; the
   preferences screen moves to `…/settings`. The plain word belongs to the
   content, which is what the bell opens.
4. `ctx.inbox.push` honours the user's in-app preference when `triggerId` names
   a registered trigger, and writes when it does not.

Server
- `user_notifications` + `model/userNotifications/`. The dedupe UNIQUE is scoped
  to the USER, narrower than the outbox's `(rule, user, channel)`: an inbox has
  no channel dimension, so two rows for one event would be one item shown twice.
- `engagement/inappChannel.js` — renders by block ROLE (first heading → title,
  first button → url, the rest → body) and inserts. `pushChannel.js` — a
  content-free `{stream, ref}` tickle whose ref deep-links the inbox row.
- `engine.liveChannels` orders `inapp` first (`CHANNEL_ORDER`) so that ref
  resolves on the first sweep. An ordering, not a dependency.
- `templates.renderInappByKey` + `resolveTemplate` extracted from `renderByKey`,
  so both channels take the same fallback chain.
- `inapp.event` seed → seedVersion 2: it named `body`/`url`, which nothing
  supplies. Renamed to the structural vocabulary the projection fills in.
- `utils/userNotificationsPrune.js` — nightly, READ items only, horizon in
  `settings.user_notifications_retain_days` (default 90).
- `GET /auth/me/notifications`, `…/unread-count`, `POST …/:id/read`,
  `POST …/read-all`. Swagger + route manifest + four component schemas.

Web
- `NotificationBell` in all three headers, polling its badge once a minute and
  pausing while the tab is hidden. `PlayerInbox` at `/account/notifications`.
- The preferences screen becomes a channel matrix over
  `/auth/me/notifications/channels` — a strict superset of the push-only stream
  list it replaces. The two legacy endpoints are untouched, so the shipped
  Android app keeps its wire shape.
- Staff get the same two screens at `/admin/notifications…`: `RequirePlayer`
  keeps them out of `/account`, so without this the inbox was unreachable for
  every non-player account. `lib/notificationPaths.js` is the one mapping.

Verified: 28 new server tests (5 of them against a real MariaDB, for the three
index/statement properties that are a server contract rather than a reading of
this code) + 3 client. Server suite green, client 327 green. A live rig walked
the whole path: two rules on one event produced three outbox rows and exactly
one inbox item, the tickle carried `ref: notification:2`, and the retention
sweep dropped an aged read row while keeping an equally aged unread one.

Docs: RunicGateway/docs#TBD, RunicGateway/runicgateway.com#TBD

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

server/db/schema.sql

@@ -1952,3 +1952,45 @@ CREATE TABLE IF NOT EXISTS engagement_digest_state (
 INSERT IGNORE INTO engagement_digest_state (user_id, channel, scope_key, last_digest_at)
   SELECT user_id, 'email', CONCAT('team:', team_id), last_digest_at
     FROM team_notification_prefs;
+
+-- ── The in-app channel (ENGAGEMENT.md §4.5 G17 — Phase 7) ──────────────────
+
+-- The inbox. Core, game-agnostic, and the first sink core owns that CARRIES its
+-- content: a push tickle deliberately holds none and an email leaves the
+-- building, so this is the one place a message both belongs to this deployment
+-- and can be read without a mailbox.
+--
+-- `dedupe_key` is the acceptance criterion, expressed as an index rather than as
+-- a check the writer has to remember: a replayed event, a retried outbox row and
+-- a module calling `ctx.inbox.push` twice all reduce to the same INSERT IGNORE.
+-- It is scoped to the USER (not to the rule and channel the outbox scopes by),
+-- because one event may legitimately be two outbox rows for one person — a rule
+-- spanning channels — and two inbox rows for it is one item shown twice.
+-- Multiple NULLs are permitted by a UNIQUE index, which is what "this item does
+-- not dedupe" means.
+--
+-- `url` is stored RELATIVE only, validated with the character class
+-- `pageUrlTemplate` and the engine's `url` variables already use: it ends up in
+-- an href on a page a signed-in user is looking at, and `//evil.test/x` passes
+-- every "is it rooted" check anyone writes by hand.
+CREATE TABLE IF NOT EXISTS user_notifications (
+  id          BIGINT AUTO_INCREMENT PRIMARY KEY,
+  user_id     INT          NOT NULL,
+  trigger_id  VARCHAR(96)  NOT NULL,
+  title       VARCHAR(300) NOT NULL,
+  body        TEXT         NULL,             -- rendered by the inapp template, sanitized on write
+  url         VARCHAR(500) NULL,             -- relative only, validated like pageUrlTemplate
+  dedupe_key  VARCHAR(190) NULL,
+  read_at     DATETIME     NULL,
+  created_at  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  CONSTRAINT fk_un_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
+  UNIQUE KEY uq_un_dedupe (user_id, dedupe_key),
+  -- Both of the two questions this table is asked: "what is in my inbox" (the
+  -- list, newest first) and "how many are unread" (the badge, on every page
+  -- load). A single index answers both because `read_at` is IS NULL in one and
+  -- unconstrained in the other, and `created_at` orders what is left.
+  INDEX idx_un_unread (user_id, read_at, created_at),
+  -- What the prune sweep queries. Without it the sweep is a table scan of every
+  -- notification this deployment has ever written.
+  INDEX idx_un_prune (created_at)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;