feat(membership): escalating background-check nudges for 18+ students

[jee7s]

What & why

cron/person-bg-annual already OPENS a PERSON_BG obligation for every
program-attached person ≥18 with no fresh check, and the compliance dashboard
shows the board who needs one — but nothing reaches the students. This PR
adds the missing half: escalating email nudges to the student's household that
carry the Averity consent deep link, with dedup plumbing so repeated daily cron
runs never re-send the same threshold.

Design doc: checkin-app/docs/designs/BG_STUDENT_NUDGES.md.

Decisions (from the product interview)

• Nudges + consent link, NO blocking. Each email carries
  backgroundCheckProvider.getConsentDeepLink() (Averity) and points at the
  self-attest path (/membership, Applicant copy overpromises: BG consent is board-gated, so 'pay right away' stalls on a human #875) for after they've submitted. Warn-only —
  no check-in or enrollment blocking (rejected alternative documented in the
  design doc).
• Schedule: open, +14d, +30d, then monthly (dueThresholdDay, a pure
  function). Two escalations in the first month while a reminder is still timely,
  then a steady monthly poke for the long tail.
• Recipients mirror the existing trusted-adult notifications
  (emailHouseholdLeads → household leads) plus the student themselves when
  they have an email on file (deduped).
• Dedup ledger: a new additive PersonBgNudge table with
  @@unique([processId, thresholdDay]). The sweep inserts before it emails, so a
  re-run at the same stage is a no-op.
• Standalone off main, not dependent on the open feat: auto-notifications as things go stale #958 sibling PR. The design
  doc spells out the fold-in: drop this table into feat: auto-notifications as things go stale #958's NotificationLedger and
  register a PERSON_BG_NUDGE type — a registration + table merge, not a rewrite.

Where it runs

New daily cron GET /api/cron/person-bg-nudge (withCron + CRON_SECRET), kept
separate from person-bg-annual so that open-obligations job stays
single-purpose. Adding the schedule is an infra follow-up (noted in the doc).

Clearing stops nudges naturally

No explicit stop signal: a submitted (bgConsentAt set), cleared
(lastBackgroundCheck stamped → ACTIVE), under-18 (MINOR), or already-fresh
subject drops out of the open-and-still-NEEDED set. The eligibility recheck
(personBgVerdict) mirrors person-bg-annual exactly.

Testing evidence

• Unit (personBgNudge.test.ts): the threshold schedule (0/14/30/monthly) +
  monotonicity; withCron auth gate (missing/wrong secret → 401, envelope on 200).
• Integration (personBgNudge.integration.test.ts): a full sweep — obligation
  open → email captured with the consent + self-attest links, sent to lead and
  student; ledger blocks a same-stage re-send; day-14 escalation fires a second
  nudge; cleared / submitted / under-18 subjects get nothing; policy-off no-op.
• Full pre-commit suite green (1716 tests), tsc --noEmit clean,
  eslint --max-warnings 0 clean. Migration applies cleanly under the
  integration harness's migrate deploy.

🤖 Generated with Claude Code