fix(engagement): claim the seed guard atomically, and let a rule name a digest body

Both defects came out of Phase 13's acceptance walk, and neither was visible to
any test.

**1. The one-shot rule-group guard was not a guard.** `seedRuleGroup` and
`coreRules.seedGroup` both read their settings stamp, inserted the whole group,
and wrote the stamp AFTER the loop. Two instances booting in the same moment both
read "absent" and both insert -- the walk ended up with 52 module rules where the
module ships 26. `docker compose up --scale app=2` and a rolling restart both
start two instances on purpose, so this is ordinary rather than exotic.

`settings.db` gains `claim(key, value)`: the same `INSERT IGNORE` as
`seedDefault`, reporting its own `affectedRows`, so exactly one caller can win a
key. The atomicity is the PRIMARY KEY's -- no transaction, no lock, the same
bargain `engagementWorker`'s row claim already makes. Both seeders claim before
inserting.

The trade the code already documented is unchanged, only its order: a process
that dies mid-loop leaves the group stamped and partly seeded, and the missing
rules are an operator's visit to the "new rule" form. A duplicate rule is two
mails per event, for every rule in the group, which both functions' own comments
already call the worse outcome.

**Why no test caught it:** the stubs supplied `get` and `set` over a Map, which
cannot race, so they agreed with the bug -- Phase 4a's `foundRows` finding in a
different costume. The fake is now `claim`-shaped and decides without yielding,
exactly as the table does, and both suites gained a test that runs two seeders
with `Promise.all` and asserts one insert each. Verified by reverting the fix:
the module test then reports every rule inserted twice.

**2. A rule that names a `digest` body could not be saved.** `registries.js`
`checkSeedRule` permits `digest` in as many words -- it is the body
`teamDigestWorker` renders for a rule whose email channel an individual set to
digest mode, so it never appears in `channels` and never could -- and
MODULE_API.md 2.4 tells modules they may point `template_keys` at
`notify.digest`. `engagementRules.model.js` then rejected any key that was not
one of the rule's channels.

So every rule shipping a digest body answered an operator who opened it and
pressed Save with a 400 naming a key they had never typed: core's own Team and
news rules, and sixteen of module-uo's. The only way to save was to delete the
digest body, silently dropping digest support from that rule. The two validators
now agree; anything that is neither a channel nor `digest` is still refused, with
a test for each direction.

No MODULE_API bump: no member is added, removed or changed, and the documented
contract is what the code now honours rather than something new.

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

server/test/engagementEmail.test.js

@@ -371,8 +371,7 @@ test('a GET on the unsubscribe endpoint mutates nothing and lands on the page',
 // ── The seeded rules (decision 3) ──────────────────────────────────────────
 
 test('core seeds a rule for each Team trigger, and every one of them is OFF', async () => {
-  patch(settingsDb, 'get', async () => null)
-  patch(settingsDb, 'set', async (k, v) => world.settings.set(k, v))
+  patch(settingsDb, 'claim', async (k, v) => { world.settings.set(k, v); return true })
   patch(rulesDb, 'insert', async (rule) => { world.inserted.push(rule); return world.inserted.length })
 
   const summary = await coreRules.seedTeamRules()
@@ -400,9 +399,32 @@ test('every seeded rule names a template that actually exists', () => {
 // Seeded once, not ensured: an operator who deletes a rule must not find it back
 // after a restart, and one they enabled must not be reset to off.
 test('a second boot seeds nothing', async () => {
-  patch(settingsDb, 'get', async () => '2026-08-29T00:00:00.000Z')
+  // The guard is a CLAIM, so "already seeded" is the claim losing rather than a
+  // read finding a row. It is the same one-shot promise, made atomically: two
+  // instances booting together used to both read "absent" and both seed, and a
+  // duplicate rule is two mails per event (Phase 13's acceptance walk).
+  patch(settingsDb, 'claim', async () => false)
   patch(rulesDb, 'insert', async () => { throw new Error('must not insert') })
   const summary = await coreRules.seedTeamRules()
   assert.equal(summary.inserted, 0)
   assert.equal(summary.skipped, 4)
 })
+
+test('two instances booting together seed the Team rules once, not twice', async () => {
+  // Not awaited in turn on purpose: interleaving the two calls is the test, and
+  // awaiting the first would pass against the read-then-write guard this
+  // replaced. `claim` decides and writes without yielding, exactly as the
+  // settings table's PRIMARY KEY does.
+  const claimed = new Set()
+  patch(settingsDb, 'claim', async (k) => {
+    if (claimed.has(k)) return false
+    claimed.add(k)
+    return true
+  })
+  patch(rulesDb, 'insert', async (rule) => { world.inserted.push(rule); return world.inserted.length })
+
+  const [a, b] = await Promise.all([coreRules.seedTeamRules(), coreRules.seedTeamRules()])
+
+  assert.equal(a.inserted + b.inserted, 4)
+  assert.equal(world.inserted.length, 4)
+})