Safe Data Backfill

Write a data backfill script.

What needs to change: [THE TRANSFORMATION, IN PLAIN TERMS]
Schema and table sizes: [PASTE THE RELEVANT SCHEMA + ROW COUNTS]
Database and version: [e.g. Postgres 16, MySQL 8, MongoDB]
Language and access pattern: [e.g. "Python with SQLAlchemy", "a psql script", "a Rails task"]
Is the system live during the backfill: [YES/NO. If yes, what writes to these rows concurrently.]
Acceptable runtime and load: [e.g. "must not add more than 10% database load", "overnight window of 4 hours"]
How rows are identified: [PRIMARY KEY TYPE, whether it is monotonic]

The script must:
- **Dry run by default.** Running it without an explicit flag reports what it would change, including counts and a sample of before and after values, and writes nothing.
- **Batch** with a configurable size, committing per batch. Never one transaction over the whole table, and never row-by-row across a large table.
- **Be resumable.** Track progress durably (a cursor table or a marker column) so an interrupted run continues rather than restarting. Make it safe to run twice: reprocessing an already-migrated row must be a no-op, not a second transformation.
- **Throttle.** A pause between batches, and a check that backs off when replication lag or load crosses a threshold. Name the specific signal to watch for my database.
- **Log** per batch: range processed, rows changed, rows skipped, errors, and elapsed time. Enough to answer "where did it get to" from the logs alone.
- **Handle concurrent writes** correctly if the system is live: state the locking or conditional-update strategy and what happens when a row changes between read and write.
- **Fail loudly.** On an unexpected row, stop and report rather than skipping silently. A backfill that quietly skips rows is worse than one that stops, because nobody finds out for months.

Also produce:
1. **The verification query** that proves the backfill is complete and correct, runnable independently of the script.
2. **The rollback plan**: whether the original values can be recovered, and if not, what to snapshot before starting. Say plainly if this migration is irreversible.
3. **The run plan**: dry run, then a small limited batch, then check, then full run. With the exact commands.

Rules: if the transformation is not reversible from the data alone, say so in your first line. Do not write a script that mutates rows in place without a way to know what they were.