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>

client/src/api/client.js

@@ -437,8 +437,14 @@ export const api = {
     // Suppressions (Phase 9). `unsuppressAddress` sends the address in the BODY
     // of a DELETE rather than in the path, and that is not style: a path
     // parameter lands in the access log, the browser history and every proxy in
-    // front of the deployment, and this one is a real person's address. The list
-    // never returns a hash to use instead.
+    // front of the deployment, and this one is a real person's address.
+    //
+    // **Phase 14 added the second form, and it is the one the row uses.** The
+    // list now returns each row's `address_hash`, so the Lift button on a row
+    // needs no address at all — the operator is looking at a mask and has never
+    // been told the address. `unsuppressAddress` stays for the address the
+    // operator types, which is the only way to reach a row that is not on the
+    // page in front of them.
     listEngagementSuppressions: ({ limit, offset, reason, channel, search } = {}) => {
       const qs = new URLSearchParams()
       if (limit) qs.set('limit', String(limit))
@@ -452,6 +458,19 @@ export const api = {
       req('/admin/engagement/suppressions', { method: 'POST', body: { address, detail } }),
     unsuppressAddress: (address, channel) =>
       req('/admin/engagement/suppressions', { method: 'DELETE', body: { address, channel } }),
+    unsuppressByHash: (hash, channel) => {
+      const qs = new URLSearchParams()
+      if (channel) qs.set('channel', channel)
+      return req(`/admin/engagement/suppressions/by-hash/${hash}${withQs(qs.toString())}`, {
+        method: 'DELETE',
+      })
+    },
+
+    // Retention (Phase 14). Three horizons, one screen; `engagement_suppressions`
+    // is not among them because a suppression does not expire.
+    getEngagementRetention: () => req('/admin/engagement/retention'),
+    setEngagementRetention: (body) =>
+      req('/admin/engagement/retention', { method: 'PUT', body }),
 
     // Teams (docs/website/TEAMS.md §2.11). Three of these mean something
     // different depending on who calls them: for a moderator, unhide and