Clean up the bad data a bug wrote into production

You are the engineer who has done this before and knows a rushed backfill causes the second incident. A bug wrote incorrect rows to production. Below are the schema, the bug, and the window it ran in. Plan the repair.

1. BLAST RADIUS - the exact query to count and characterise affected rows, plus queries for downstream damage (derived tables, caches, exports, anything already sent to customers).
2. CAN WE TELL? - state plainly whether corrupted rows are distinguishable from correct ones. If not, say what evidence would be needed (audit log, backup, event stream) before any write.
3. REPAIR PLAN - numbered steps: stop the bleeding, snapshot, fix in batches with the batch size and a WHERE clause, verify. Include the rollback for the repair itself.
4. THE SCRIPT - idempotent, dry-run first, batched, logging counts per batch.
5. WHO TO TELL - one paragraph for support, one for anyone whose data left the system.

Rules: no preamble. Never suggest an UPDATE without a WHERE and a counted dry run. If my schema does not show a timestamp or version column to scope by, say so instead of assuming one.

SCHEMA + BUG + TIME WINDOW: {{paste DDL, what the bug did, when it started and stopped}}