feat(engagement): retention — three sweeps and one recorded refusal

ENGAGEMENT.md Phase 14, the last phase of the workstream. Four engagement
tables grew on every fire and nothing had ever deleted from any of them.

Three of them now have a horizon, swept nightly by one worker
(utils/engagementRetentionPrune.js — setInterval + unref + stop(), batched
1000 x 50, each table's failure caught on its own so a lock timeout on one
does not leave the other two unbounded):

  engagement_sends      180 days   engagement_sends_retain_days      (7-3650)
  engagement_cooldowns   30 days   engagement_cooldowns_retain_days  (2-3650)
  engagement_outbox      30 days   engagement_outbox_retain_days     (2-3650)

The fourth, engagement_suppressions, does not expire, and that is the
recorded decision rather than an omission: a suppression is a standing
decision, and ageing out a hard bounce re-mails an address that already
bounced. The way out stays deliberate, and is now reachable per row.

Six decisions were settled by the org lead before any code. Two of them
widened the phase past what was offered:

  * the send-log horizon is admin-configurable, so retention got a SCREEN
    (Admin -> Engagement -> Retention) where team_activity and
    user_notifications keep theirs in invisible settings rows. The send-log
    horizon changes what an operator-facing page is able to show, so it has
    to be visible; the other two came with it, because "what does this
    deployment keep" is one question.
  * the suppression purge, which cost a Phase 9 decision. The list
    deliberately stripped address_hash from every row, so the only way out
    was a window.prompt asking the operator to retype an address the screen
    has never shown them. The row had no handle at all. The hash is now
    returned: this route is admin-only and an admin can already suppress and
    unsuppress any address they can name, so it grants no capability they
    lack. GET /sends still strips its own.

The outbox sweep is TERMINAL-ONLY and that is a correctness rule: a
scheduled row is a send this deployment still intends to make (delay_seconds
can put one a day out) and a sending row may be mid-flight.

One shipped defect had to be fixed for the sweep to be a bound at all.
reclaimStale returned every stale sending row to scheduled, and MAX_ATTEMPTS
is consulted only on a graceful retry outcome — so a send that killed the
process mid-flight cycled sending -> scheduled -> sending forever, never
terminal, therefore never eligible for any sweep. It now fails an exhausted
row BEFORE reclaiming the rest; the order is the fix.

Two indexes (idx_engo_sweep, idx_engs_sweep): every existing index on those
tables has created_at in second position, which serves a per-rule window and
is useless to a whole-table horizon.

Proved twice: engagementRetentionSql.test.js against a real MariaDB (7
tests, incl. the acceptance case and the wrong reclaim order run
deliberately), and the live stack, where a 90-day-old cancelled row was
swept and a 90-day-old scheduled row survived.

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

server/db/schema.sql

@@ -1850,7 +1850,10 @@ CREATE TABLE IF NOT EXISTS engagement_outbox (
   INDEX idx_engo_due (status, due_at),
   -- What a RESOLVING event queries: a house repaired back to LikeNew cancels
   -- every scheduled row for that (rule, user, house).
-  INDEX idx_engo_cancel (rule_id, user_id, subject_key, status)
+  INDEX idx_engo_cancel (rule_id, user_id, subject_key, status),
+  -- Phase 14. The sweep is `status IN (terminal) AND created_at < ?`, and
+  -- `idx_engo_due` cannot serve it: its second column is `due_at`.
+  INDEX idx_engo_sweep (status, created_at)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
 -- G15: the per-message record. Today "did user X get the mail?" is unanswerable.
@@ -1877,7 +1880,11 @@ CREATE TABLE IF NOT EXISTS engagement_sends (
   INDEX idx_engs_user (user_id, created_at),
   -- The per-rule hourly ceiling (§7.1 Q3) is counted here, so the count has to be
   -- an index range scan rather than a table scan: it runs once per rule per event.
-  INDEX idx_engs_rule_window (rule_id, created_at)
+  INDEX idx_engs_rule_window (rule_id, created_at),
+  -- Phase 14's retention sweep deletes by age alone, so it needs `created_at`
+  -- LEADING. Every index above has it in second position, which serves a
+  -- per-rule or per-user window and is useless to a whole-table horizon.
+  INDEX idx_engs_sweep (created_at)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
 -- §4.4. The mail (and, from Phase 7, in-app) bodies an operator can edit, stored
@@ -1937,6 +1944,14 @@ CREATE TABLE IF NOT EXISTS engagement_templates (
 -- link in it. Same vocabulary as engagement_digest_state.scope_key below.
 ALTER TABLE engagement_outbox ADD COLUMN IF NOT EXISTS scope_key VARCHAR(190) NULL;
 
+-- Phase 14 (retention). The two sweep indexes, for deployments whose tables
+-- predate them. `IF NOT EXISTS` on an index is MariaDB-only and already used
+-- above (`idx_wiki_search`), so this needs no INFORMATION_SCHEMA guard like the
+-- cooldown primary-key change did -- that one needed one because MariaDB has no
+-- conditional form of a PRIMARY KEY change, not because indexes lack one.
+ALTER TABLE engagement_outbox ADD INDEX IF NOT EXISTS idx_engo_sweep (status, created_at);
+ALTER TABLE engagement_sends ADD INDEX IF NOT EXISTS idx_engs_sweep (created_at);
+
 -- §4.2b: digest state, and DELIBERATELY not a digest queue.
 --
 -- The generic engine enqueues an outbox row per (rule, user, channel) at emit