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/index.js

@@ -44,6 +44,8 @@ module.exports = function register(ctx, api) {
   const usersShardExtension = require('./router/admin/usersShard.router')
 
   const shardStreams = require('./config/shardStreams')
+  const shardTriggers = require('./config/shardTriggers')
+  const shardAudiences = require('./config/shardAudiences')
   const townCrierLeg = require('./utils/shardAnnounce')
   const teamProvider = require('./model/teamProvider/teamProvider.model')
   const guildCommand = require('./commands/guild.command')
@@ -88,6 +90,31 @@ module.exports = function register(ctx, api) {
   api.registerNotificationStreams(shardStreams.STREAMS)
   api.registerAnnounceLeg(townCrierLeg.leg)
 
+  // The engagement contract (MODULE_API 1.7.0, ENGAGEMENT.md Phase 11). Triggers
+  // are PAYLOAD contracts: what a rule may fire on, what a template may
+  // interpolate, and — the part that is a security boundary — the widest audience
+  // an operator may ever give each one. `uo.cheat.detected` ceilings at `staff`
+  // and the three operator-facing ones at `admin` (added to the lattice in 1.8.0),
+  // and core refuses a rule that widens either.
+  //
+  // **Triggers and notification streams share ONE id namespace** (§7.2), so this
+  // registration and the one above are two facets of one space and core enforces
+  // that an id has exactly one owner across both. None of the ids below reuses a
+  // stream id: the stream catalog keeps its seven grandfathered names and these
+  // are the `uo.*`-prefixed ones §8.6 specifies. A trigger-only id gets email and
+  // in-app preferences and no push toggle, which is correct — there is nothing to
+  // push it to, and the shipped Android client's catalog is unchanged.
+  api.registerEventTriggers(shardTriggers.TRIGGERS)
+
+  // Audiences are named sets of PEOPLE an operator composes rules and segments
+  // out of (§5.1a). Their own id space, and their own ceiling arithmetic: a
+  // composition takes the narrowest ceiling it contains, never the widest.
+  //
+  // Registration is a claim; nothing resolves until the engine asks, which is
+  // after `onBoot` — and it must be, because every resolver reads the database
+  // and registration must not (§2.2 rule 1).
+  api.registerAudiences(shardAudiences.AUDIENCES)
+
   // Teams: a UO guild is a Team, and this module is the authoritative source of
   // them for this deployment (MODULE_API 1.6.0). Core asks the three questions;
   // everything about what a guild IS stays here.
@@ -114,5 +141,7 @@ module.exports = function register(ctx, api) {
     version: require('../module.json').version,
     routes: 'public:/shard,/atlas admin:/shard,/uo-link player:/shard',
     streams: shardStreams.STREAMS.length,
+    triggers: shardTriggers.TRIGGERS.length,
+    audiences: shardAudiences.AUDIENCES.length,
   })
 }