fix(engagement): two defects the Phase 11b live walk found in core

Both are invisible to a fixture and loud on a real database, which is why the
walk is the phase's acceptance rather than a formality.

1. registerEngagementSeeds validated `max_sends_per_hour` and then dropped it
   from the normalized rule. The column is NOT NULL, so every one of the 25
   module-seeded rules failed to insert at boot. The registry test asserted the
   REJECTION of a bad ceiling and never that a good one survives; it now asserts
   the normalized rule against `engagementRules.db.insert`'s own column list, so
   the next field added is covered the day it is added.

2. The cooldown claim runs inside the engine's per-channel loop and its key was
   (rule, user, subject). So the first channel of a rule claimed the cooldown and
   every later one was reported as cooled -- and `inapp` is ranked first
   deliberately, so a rule naming email + in-app delivered the inbox item and
   silently never the mail. Core's own `news.post` rule has that shape. Phase
   11b's decision 8 requires the letter and the inbox item to fire together.

   `channel` joins the PRIMARY KEY (the org lead's decision 12: a cooldown is per
   delivery, not per occasion). Migrated in place behind an information_schema
   guard, because MariaDB has no conditional form of a key change and replaying
   schema.sql would otherwise fail on every boot after the first.

1551 core tests green; both new tests verified by reverting each fix in turn.

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

server/src/engagement/engine.js

@@ -203,9 +203,18 @@ async function applyRule(rule, event, now) {
         summary.capped += 1
         continue
       }
-      // One statement, guarded on the interval, so two concurrent emits cannot
-      // both pass a read-then-write check (§4.1).
-      const allowed = await cooldownsDb.claim(rule.id, userId, subjectKey, rule.cooldown_seconds, now)
+      // Guarded on the interval, so two concurrent emits cannot both pass a
+      // read-then-write check (§4.1).
+      //
+      // **Keyed on the CHANNEL as well**, which is what makes this loop correct
+      // rather than what makes it work. Without the channel, the first channel of
+      // a rule claims the cooldown and every later one is refused as cooling —
+      // and `inapp` is ranked first above, so a rule naming email + in-app would
+      // deliver the in-app item and silently never the mail. Found on Phase 11b's
+      // live rig; a cooldown is per delivery, not per occasion.
+      const allowed = await cooldownsDb.claim(
+        rule.id, userId, subjectKey, channel, rule.cooldown_seconds, now,
+      )
       if (!allowed) {
         summary.cooled += 1
         continue