feat(rust): notifications and engagement (phase 10, protocol 7)

Registers the engagement set R7 put in v1: thirteen triggers, four push
streams, three audiences, four bodies (two triggers, email and in-app)
and thirteen disabled rules in seven groups (PLAN.md §25, D59-D68).

The raid alert goes to everyone authorised on the tool cupboard, one
emit per linked person with ownerUserId, so the owner ceiling holds per
emit. It covers doors and walls (protocol 7), never names the raider,
alerts nobody when there is no cupboard, and carries ownerOnline so
"offline only" is the seeded rule's condition rather than code.

The fan-out runs off ingest before a frame is applied, since applying a
disband deletes the roster the notice is sent to. A replayed event is
told only while it is news: 15 minutes for broadcasts, 24 hours for
personal and staff events. Dedupe keys come from the event, not the
sidecar's row id. Server online/offline and a new kills leader are
in-memory transitions, never on first sight, and a tie is not a lead.
A login with no approval within a minute becomes a staff notice via a
query, so a restart loses nothing.

Also fixes a phase-4 gap (D68): the refresh now asks /health, so a game
that hung, or whose bridge was unloaded, while the sidecar stayed up no
longer reads as online. It stops naming players as online, and a stale
board no longer moves "last seen".

engagement-triggers.json is the committed freeze of all of it, checked
in CI with line endings normalised. The check was verified by breaking
it both ways.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

server/model/events/events.db.js

@@ -272,6 +272,38 @@ async function presenceFor(serverId) {
   )
 }
 
+/**
+ * Login attempts in `[from, to]` that no approval answered (D64).
+ *
+ * An attempt is answered by a `player.approved` for the same Steam id on the
+ * same server stamped from `slackMs` before it to `windowMs` after it. The
+ * slack is clock grain: both frames come off one game thread, and an approval
+ * stamped a millisecond "early" is still the answer.
+ *
+ * Grouped on (steam id, t) because a cursor replayed after a crash can store the
+ * same attempt twice, and one attempt is one denial however often it was
+ * written down.
+ */
+async function unapprovedLogins({ serverId, from, to, windowMs, slackMs }) {
+  return core.query(
+    `SELECT a.steam_id AS steamId, a.t AS t,
+            MAX(JSON_UNQUOTE(JSON_EXTRACT(a.raw, '$.name'))) AS name
+       FROM ${EVENTS} a
+      WHERE a.server_id = ? AND a.kind = 'player.login.attempt'
+        AND a.steam_id IS NOT NULL AND a.t BETWEEN ? AND ?
+        AND NOT EXISTS (
+          SELECT 1 FROM ${EVENTS} b
+           WHERE b.server_id = a.server_id AND b.kind = 'player.approved'
+             AND b.steam_id = a.steam_id
+             AND b.t BETWEEN a.t - ? AND a.t + ?
+        )
+      GROUP BY a.steam_id, a.t
+      ORDER BY a.t ASC
+      LIMIT 200`,
+    [serverId, from, to, slackMs, windowMs],
+  )
+}
+
 module.exports = {
   getCursor,
   setCursor,
@@ -286,4 +318,5 @@ module.exports = {
   leaderboard,
   listWipes,
   presenceFor,
+  unapprovedLogins,
 }