Persist snooze until and reopen it with a periodic sweep (CL-7208)

[TheGreatAxios]

Summary

Stacked on #510 (CL-7207, cl-7207-bulk-ops-atomicity), which is itself stacked on #486 (CL-7206). Base this PR against cl-7207-bulk-ops-atomicity, not main, until both merge.

POST /:id/snooze accepted an until timestamp, validated its type, and echoed it back in the response — but the store call underneath only ever flipped the mailbox row's status to "snoozed". Nothing recorded until or ever reopened the item: a snoozed approval or credential-reconnect sat under the snoozed filter forever, invisible, with no reminder ever firing.

Changes

• packages/inbox/src/schema.ts (new): @corbits/mailbox's enrichMailboxMessage only supports priority/classification/status — no column for a timestamp — so this adds the one product table @corbits/inbox needs: inbox.snooze (tenantId, principalId, messageId, until), its own Postgres schema, following @workbench/onboarding's pattern for a package-owned table.
• packages/inbox/src/migrations.ts: applyInboxMigrations, the same hand-rolled ledger-table pattern as onboarding/routines/notify, registered in scripts/db-setup.ts's INSTALLED_PACKAGE_MIGRATIONS as @corbits/inbox.
• packages/inbox/src/snooze-store.ts (new): setSnoozeUntil/clearSnoozeUntil, findDueSnoozes (a bare, non-claiming SELECT), and claimAndReopenSnooze — a single transaction that deletes the due row and, only if that succeeds, flips the message back to open if it's still snoozed. Two replicas racing the same row: the second's DELETE ... RETURNING simply returns nothing (the first already deleted it). A throw anywhere inside rolls the whole transaction back, so a failed claim leaves the snooze row exactly as it was for the next tick to retry — the same mail-then-claim ordering lesson CL-7209 applied to the credential-expiry sweep, applied here to the claim itself.
• packages/inbox/src/routes.ts: /:id/snooze now requires until, parsed at the boundary with arktype (never as-cast) per AGENTS.md, and rejects with 400 if it doesn't parse as a valid timestamp or has already passed — silently snoozing forever is exactly the bug being fixed, so a past until is refused rather than accepted or silently reopened. Both the snooze-until write and the status flip run inside one db.transaction (see "Race found and fixed" below for why).
• apps/hub/src/inbox-unsnooze-sweep.ts (new): a small periodic sweep (tickInboxUnsnoozeSweep/createInboxUnsnoozeSweep) mirroring credential-expiry-sweep.ts and routine-scheduler.ts — the only other periodic loops in this hub — rather than inventing a new scheduling primitive.

Which scheduling primitive, and why not the others

I checked @corbits/notify's createNotifyDispatcher and @corbits/routines' scheduler machinery first. Neither fits:

• createNotifyDispatcher is shaped around external-sink delivery (attempts, backoff, a SinkRegistry) — a status flip on our own table isn't a delivery, and bending its retry/attempt semantics onto this would be a worse fit than writing the ~15 lines this needs directly.
• The routine scheduler's RoutineStore is routine-domain-specific (fire schedules, launches) — nothing here is a routine.

The actual fit is the pattern both routine-scheduler.ts and credential-expiry-sweep.ts already use: a small setInterval tick, a listDue*/claim* store method, a standalone exported tick function for deterministic tests. That's exactly what CL-7209 reused too (the credential-expiry sweep's own due-scan, not a new mechanism) — this PR repeats that established idiom rather than building a third parallel poller shape. Wired into apps/hub/src/index.ts's createHub() next to credentialExpirySweep, sharing the existing mailboxDb/mailboxBus, stopped in shutdown alongside the others.

Race found and fixed mid-review

A Critique pass on the first two commits found and reproduced against a real Postgres a genuine race: persisting until and flipping status to snoozed as two independent statements let a concurrent sweep tick's claimAndReopenSnooze land in the gap — see the row before the flip, find the message not yet snoozed, no-op, and delete the row as harmless-looking cleanup — and then the route's own status flip would still land afterward, leaving the message stuck snoozed with the row that was supposed to reopen it already gone. That is exactly this ticket's bug, reintroduced by the un-transacted write order.

Fixed by running both writes in one db.transaction: an uncommitted insert is invisible to any other transaction under read-committed isolation, so a concurrent claim can never observe the row until the status flip has also committed alongside it. The third commit adds a regression test that races the route's own write against a concurrent claim and asserts the message is never left snoozed with its row gone — verified red-then-green against a real Postgres (reproducibly failed before the fix across 8/8 runs, passed 8/8 after).

Tests

• Route-level: rejects a missing/non-string/unparseable/past until (routes.test.ts).
• packages/inbox/test/snooze-store.test.ts (DB-gated, scratch-database pattern from delivery.test.ts): persists and reads back a due row, claims and reopens it, a second claim on an already-claimed row returns false, a no-longer-snoozed message's stale row gets cleaned up without a spurious reopen, and the TOCTOU regression test above. Ran against a real local Postgres repeatedly during development, not just typechecked.
• apps/hub/test/inbox-unsnooze-sweep.test.ts: DB-free unit test of the tick loop against a fake store — reopens every due row and publishes once per actual reopen, doesn't publish on a no-op claim, and a per-row throw is swallowed (reported, not propagated) so one bad row can't abort the rest of the tick.

Verification

• cd packages/inbox && bun run typecheck && bun test — 44 pass (unit), 9 skip locally (DB-gated, no DATABASE_URL in CI-less local runs) — separately ran with a real Postgres: 49 pass, 0 fail, including the new migration genuinely applying (@corbits/inbox: 0001_snooze).
• cd apps/hub && bun run typecheck && bun test test/inbox-unsnooze-sweep.test.ts — 3 pass, 0 fail.
• bunx prettier --check and bunx eslint on all touched/new files — clean.
• Reviewed by Greybeard (approach, before writing code — caught wrong precedent claims, the wrong migration pattern, and the write-order gap that became the regression test) and Critique (implementation, twice — the second pass found the TOCTOU race above).

Linear: CL-7208