MNTOR-5244: backfill stale primary_sha1 / email_addresses.sha1

[mansaj]

References:

Jira: MNTOR-5244

Description

Subscribers who changed their email before the MNTOR-5219 fix (ac7f41289, 2026-02-27) kept a primary_sha1 / email_addresses.sha1 computed from their old email. Because the breach-alert notifier matches on these stored hashes while the dashboard re-hashes the user's current email and queries HIBP live, those users can receive a breach alert that never appears on their dashboard (surfaced in MNTOR-5286). MNTOR-5219 fixed this going forward but shipped no backfill.

Measured impact on prod (2026-05-29):

• Stale subscribers.primary_sha1: 66,446 / 11,680,354 verified (0.57%)
• Stale email_addresses.sha1: 11,906 / 2,770,362 verified (0.43%)
• Distinct subscribers affected: 67,892 (13,206 active within the last year)
  This PR adds a one-off, batched, idempotent maintenance script that realigns each stored hash with getSha1(lower(email)).

Screenshot (if applicable)

Not applicable.

How to test

• npm run test-integrations -- src/db/backfillStaleSha1.integration.ts — 4/4 pass: realigns stale verified rows, leaves correct rows untouched, skips unverified rows, idempotent on re-run, dry-run writes nothing; covers both tables.
• prettier --check and eslint clean on new files; tsc reports no errors in new files.
• node esbuild.cronjobs.js emits dist/scripts/cronjobs/backfillStaleSha1.js.
• Prod dry-run (npm run script:backfill-stale-sha1 -- --dry-run) reports stale counts matching the blast radius above (~66,446 primary / ~11,906 secondary).
• Prod run off-peak; re-run the stale-count queries and confirm stale_primary = 0 / stale_secondary = 0.

Checklist (Definition of Done)

• Commits in this PR are minimal and have descriptive commit messages.
• I've added or updated the relevant sections in readme and/or code comments
• I've added a unit test to test for potential regressions of this bug.
• Product Owner accepted the User Story (demo of functionality completed) or waived the privilege.
• All acceptance criteria are met.
• Jira ticket has been updated (if needed) to match changes made during the development process.
• Jira ticket has been updated (if needed) with suggestions for QA when this PR is deployed to stage.

[Vinnl]

Thanks! I don't think I have an easy way to get my local setup in a configuration that I can reproduce this, but nothing major jumped out to me from the code - though I think the suggestion about aborting when modifying more than one row might be good to implement still.