Brief a coding agent to write a data backfill script with a dry run

Goal: Write a backfill script at {{script_path}} (for example scripts/backfill_order_totals.py) that {{backfill_change}} for the records that match {{selection_rule}}, with a dry run, so that the data can be corrected in batches while the application keeps running.

Context:
- Tables and columns involved, with their types and indexes:
"""
{{schema}}
"""
- An existing script or management command to copy for database access, configuration and logging: {{pattern_file}}
- Database and approximate row counts: {{database_details}}
- Expected counts, from queries I ran on staging: {{expected_counts}}
- Test command: {{test_command}}
- Command to run the script against staging in dry-run mode: {{staging_dry_run}}

Constraints:
- Dry run is the default. The script writes only when given an explicit flag such as --execute, and the dry run prints the same counts the real run would change, plus before and after values for a sample of {{sample_size}} records.
- Idempotent: select only rows that still need the change (for example WHERE new_column IS NULL), so a second run changes nothing.
- Batched: walk the table by primary key ranges (keyset, not OFFSET), with a configurable batch size and an optional pause between batches. Each batch commits in its own short transaction, and the script can resume with --start-after-id.
- Log each batch: ID range, rows matched, rows changed, time taken. Print a summary at the end.
- Write through a path that does not trigger side effects such as emails, webhooks or cache events from model save hooks, or stop and tell me if there is no such path.
- Read connection settings from the environment the way the pattern file does; never put a connection string or credential in the script.
- No schema changes in this task. Do not touch {{off_limits}}.
- Never run the script with --execute against any database. Production runs are mine.

Tests, in the project's existing test setup:
- A dry run changes nothing.
- An execute run changes exactly the matching rows and no others.
- A second execute run changes zero rows.
- Batch edges: a table with exactly one batch of matching rows, and one with one row more.

Done when:
- {{test_command}} passes.
- {{staging_dry_run}} reports counts that match {{expected_counts}}. If they differ, stop and report the difference with sample IDs; do not adjust the selection to make them match.

Verify: run the tests and the staging dry run, then report in this format: Usage (flags and examples), Dry-run counts next to the expected ones, Sample of before and after values, Time per batch and estimated total run time, Commands run with the last 20 lines of their output.