feat(account): hold account deletion and data wipe for a grace window

Deleting an account, a guardian deleting a managed profile, and "Delete
all data" were final the moment they were confirmed: the account row
cascaded into every table and every stored copy, and the off-host objects
were purged in the same breath. Nothing short of rolling the whole
instance back could return one account.

ACCOUNT_DELETION_GRACE_DAYS (14 by default, at most 30, 0 erases at once
as before) now sets a window:

- Account and managed-profile deletion lock the account (migration 0488:
  deletion_requested_at, deletion_purge_at, deletion_requested_by_id).
  Every session, refresh token, API token, connector, share link and
  step-up elevation is revoked in the same transaction, and the record,
  its stored copies and its off-host objects are left as they are.
- Sign-in is refused with 403 auth.account.deletion_pending and the
  erasure date, after the credential was proved and before a second
  factor is asked for. The session and Bearer resolvers and the acting-
  account resolver refuse a pending account too, so a credential minted
  in the moment before the lock is useless.
- POST /api/admin/users/{id}/undo-deletion (cookie-only, audit-logged)
  clears the lock. The admin users list reports the pending state.
- The hourly account-deletion-purge job erases accounts whose window has
  ended, exactly as the immediate deletion did, with the off-host purge
  request committed alongside. The Guardian invariant is decided again;
  a refused erasure stays pending and is reported.
- A wipe first stores the whole record as a PRE_WIPE_<ms> copy through
  the writer the weekly copy uses, keeps it out of the wipe, and holds
  its off-host purge back with a new not_before on the request. The
  ordinary restore brings the record back; restoring that copy withdraws
  the held purge. The purge job deletes the copy when its window ends.

Background work skips accounts pending deletion through one shared
predicate (src/lib/account-deletion/active-account.ts): every reminder,
digest, Coach, sync, backfill, rollup, score and backup enumeration
filters with it, and account-deletion-enumeration-guard.test.ts fails on
a query in background work that neither filters nor says why it need
not. Notification delivery and the AI capability loader refuse a pending
account as chokepoints behind it, and the Withings, WHOOP and Telegram
webhooks and the notification quick actions ignore one.

The privacy summary publishes the window. Two pieces of the reminder tick
and the off-host pass moved into modules of their own to keep the files
inside their size ratchet.

src/lib/api-errors.ts

@@ -20,6 +20,8 @@ import { RECORD_FENCE_ERROR_CODE } from "./sharing/record-session-fence-contract
  * HttpError without one serialises exactly as before.
  */
 export class HttpError extends Error {
+  /** Machine fields for the envelope's `meta`, beside `errorCode`. */
+  extraMeta?: Record<string, unknown>;
   constructor(
     public statusCode: number,
     message: string,
@@ -68,8 +70,36 @@ export const AUTH_ERROR_CODES = {
    * drops a perfectly good session because the database blinked. Retry.
    */
   sessionUnavailable: "auth.session.unavailable",
+  /**
+   * The credentials are right, but the account is pending deletion: it is
+   * locked until the grace window ends and then erased. 403, and the envelope
+   * carries `meta.purgeAt` so the sign-in screen can name the date. Only an
+   * admin can undo it, so a client stops retrying and says so.
+   */
+  deletionPending: "auth.account.deletion_pending",
 } as const;
 
+/**
+ * Sign-in refused because the account is pending deletion.
+ *
+ * Raised only after the credential itself was proved (the password checked,
+ * the passkey assertion verified, the identity provider answered), so it
+ * tells nobody anything they could not already sign in to learn. `purgeAt` is
+ * when the purge job erases the account; null only on a row whose window was
+ * never stamped, which the purge job treats as due.
+ */
+export class AccountDeletionPendingError extends HttpError {
+  constructor(public readonly purgeAt: Date | null) {
+    super(
+      403,
+      "This account is scheduled for deletion and is locked. An admin can undo the deletion until it completes.",
+      AUTH_ERROR_CODES.deletionPending,
+    );
+    this.name = "AccountDeletionPendingError";
+    this.extraMeta = { purgeAt: purgeAt ? purgeAt.toISOString() : null };
+  }
+}
+
 /**
  * The session lookup failed, as opposed to finding nothing.
  *