feat(engagement): declare 24 shard triggers and 3 audiences (Phase 11a)

module-uo's half of ENGAGEMENT.md Phase 11: every trigger DECLARATION, the
wire-kind mapping that fires them, and the three registered audiences. No rule
and no template is seeded here -- that is 11b -- so nothing this adds sends
anybody anything until an operator writes a rule.

server/config/shardTriggers.js declares the 24, grouped by the audience kind
each family exercises, and every variable carries the `example` the template
editor previews and test-sends with. Ceilings: 10 `owner`, 2 `members`, 7
`authenticated`, 2 `staff`, 3 `admin` (the value core adds in the same window).
`uo.cheat.detected` at `staff` is the declaration the lattice exists for.

server/utils/shardEngagement.js maps the wire to those ids, hung off
shardIngest.ingest beside the SSE broadcast and the push tickle, and reads like
shardPush.js on purpose -- owner resolution is why neither can be a pure mapper.
Three things live here because a rule cannot express them:

  * Transitions. champ.update and city.update are full-state upserts, so without
    a per-process tracker a sidecar reconnect reads as twenty spawns starting.
    A FIRST sighting is never a transition.
  * Thresholds. conditions.js compares a declared variable against a LITERAL, so
    "within 24 hours of dismissal" is not expressible; and vendor.listing is a
    sweep frame re-emitted on any price change, so per-frame would flood. The
    crossing is tracked here and `hoursRemaining` is declared so an operator can
    still narrow with `is at most`.
  * The members audience. "The members of THIS guild" differs every firing, so
    it travels on the envelope as recipientUserIds (Phase 6 decision 2).

**The fan-out runs BEFORE the state write, and that ordering is load-bearing.**
account.unlinked drops the shard_account_links row that names the one person who
needs to be told; house.remove drops the house whose stored ownerAcct is the only
place a collapsed house's owner appears; guild.leave/remove need the roster and
board mirrors to name who left. Resolving afterwards finds nobody, every time.

Four rows of 8.6 deliberately do not ship, each with its reason recorded in
docs (docs#194): uo.market.item_listed (a saved search, no per-user query store),
uo.guild.joined (core's team.member.joined already fires for it -- a UO guild IS
a Team and this module is the provider), uo.link.requested (no addressable
recipient by construction, ~5-minute TTL), and uo.points.rank_changed's personal
half (top[] names a serial, links are keyed by account).

coreApi -> ^1.8.0: the module now calls registerEventTriggers and declares
`ceiling: 'admin'`, so a 1.7.0 core would refuse the ceiling and a 1.6.0 one
would not have the method at all.

39 new tests; 509/509 pass. check:imports, check:bundle and check:swagger clean.

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

server/utils/shardIngest.js

@@ -20,6 +20,7 @@ const uoLinkConfigModel = require('../model/uoLinkConfig/uoLinkConfig.model')
 const { settings: settingsModel } = require('../core')
 const broadcaster = require('./shardBroadcast')
 const shardPush = require('./shardPush')
+const shardEngagement = require('./shardEngagement')
 const defaultLog = require('../core').logger('shard-ingest')
 
 // Notable kinds appended to the shard_events log. High-frequency/session kinds
@@ -62,6 +63,11 @@ const LOGGED_KINDS = new Set([
 const state = { bootId: null }
 function reset() {
   state.bootId = null
+  // The engagement mapper's transition/threshold tracker is per-process state of
+  // exactly the same kind as `bootId`, so it is reset by the same call. A test
+  // that reset one and not the other would see a champion spawn that started in
+  // the previous test.
+  shardEngagement.reset()
 }
 
 // Should this event be written to the append-only log?
@@ -285,6 +291,7 @@ function resolveDeps(deps) {
     settings: deps.settings || settingsModel,
     broadcast: deps.broadcast || broadcaster.broadcast,
     pushDispatch: deps.pushDispatch || shardPush.fromShardEvent,
+    engagement: deps.engagement || shardEngagement.fromShardEvent,
     log: deps.log || defaultLog,
   }
 }
@@ -300,6 +307,34 @@ async function ingest(event, deps = {}) {
   let stored = false
   let logged = false
 
+  // **The engagement fan-out runs BEFORE the state write, and that ordering is
+  // load-bearing rather than incidental** (ENGAGEMENT.md Phase 11). Three of the
+  // mappings read a row that `applyStateChange` is about to delete or replace:
+  //
+  //   • `account.unlinked` drops the `shard_account_links` row — the row that
+  //     turns the account into the one person who needs to be told it was
+  //     unlinked. Resolving afterwards finds nobody, every time.
+  //   • `house.remove` drops the house, whose stored `ownerAcct` is the only place
+  //     the owner of a collapsed house is named (the frame carries a serial alone).
+  //   • `guild.leave` / `guild.remove` need the roster and the board mirror to
+  //     name who left and which guild it was.
+  //
+  // Awaited, unlike the broadcast and the push tickle below, and this is the one
+  // place this file waits on a notification path. It has to: the whole point is
+  // that the read happens first, and a fire-and-forget promise would race the
+  // DELETE it is trying to precede. `fromShardEvent` never throws and never opens
+  // a socket — it resolves ids and hands the engine an envelope, which does its
+  // own work off the caller's stack (`emit` is deliberately not awaited inside).
+  // Backfilled frames are excluded for the same reason the broadcast is: a
+  // reconnect replay must not re-notify anyone about events from hours ago.
+  if (!deps.fromBackfill) {
+    try {
+      await d.engagement(event)
+    } catch (err) {
+      d.log.warn('engagement fan-out failed', { kind: event.kind, message: err.message })
+    }
+  }
+
   try {
     await applyStateChange(event, d)
   } catch (err) {