Replace print() debugging with structured logging that survives production

Migrate the print() calls in this code to proper structured logging. This is not a find-and-replace of print with logging.info — every call needs the right level, and the logger needs to be configured the way a real service actually configures logging.

CODE
A batch job that prints progress every 1000 rows, prints the full row dict on error, and prints a final summary.

RUNTIME CONTEXT
A Celery worker running inside a Docker container; stdout/stderr are captured by the container runtime and shipped to a log aggregator.

CONTEXTUAL FIELDS NEEDED
job_id, batch_size, and the row's primary key when logging a per-row failure.

LOG AGGREGATION TARGET
Logs are shipped to a system expecting JSON lines with a "message" and "level" key at minimum.

REQUIREMENTS
1. Get the logger with logger = logging.getLogger(__name__) at module level, never the root logger directly and never a logger configured inside a function that runs on every call — logging configuration (handlers, formatters, levels) belongs in one place at application startup, not scattered across modules.
2. Choose the right level per call based on what it actually reports: DEBUG for detail only useful while actively debugging, INFO for normal operational events worth keeping, WARNING for something recoverable but worth a human's attention, ERROR for a failure that needs investigation, CRITICAL only for something that threatens the whole process. A print() that was really tracking "did we get here" during development is DEBUG, not INFO — don't upgrade its importance just because it's becoming a real log call.
3. Attach job_id, batch_size, and the row's primary key when logging a per-row failure. as structured fields (via logging's extra= parameter, or a structured logging library if Logs are shipped to a system expecting JSON lines with a "message" and "level" key at minimum. expects JSON lines), not interpolated into the message string — a field baked into the string can't be filtered or aggregated on later, where a structured field can.
4. Use logger.exception(...) inside an except block when logging a caught error, so the traceback is captured automatically — don't manually format str(exc) and lose the stack trace that would have told someone where it actually happened.
5. Never log a secret, credential, or full request/response body containing personal data — if A batch job that prints progress every 1000 rows, prints the full row dict on error, and prints a final summary. currently prints something like that, flag it explicitly and log a redacted or truncated version instead, don't just move the same leak into the log aggregation pipeline.
6. Use %s-style lazy formatting (logger.info("processed %s items", count)) rather than an f-string in the log call, so string formatting doesn't run at all when the message would be filtered out by the configured level.
7. Where a print() was actually the only visible signal of progress on a long-running job, don't just downgrade it to a DEBUG log and let it disappear from default output — decide explicitly whether A Celery worker running inside a Docker container; stdout/stderr are captured by the container runtime and shipped to a log aggregator. needs an INFO-level heartbeat instead (a periodic "processed N of M" line) so the operational visibility the print() gave for free isn't quietly lost in the migration.

OUTPUT FORMAT
1. The migrated code.
2. A table: each original print() call, the level it became, and why that level.
3. Anything flagged under the secrets/PII rule, and what changed.
4. One sentence on whether any operational visibility the original print() calls provided was preserved at an appropriate level, or explicitly and deliberately dropped.