### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

A managed batch whose request lines all failed reaches a terminal provider status (`completed`) with `output_file_id=None` and only an `error_file_id`. The `CheckBatchCost` background job never transitions that row: `batch_processed` stays `false` indefinitely, so the job query re-selects the same row on every polling cycle for the lifetime of the deployment.

There is no exception. The provider retrieve succeeds and returns a correct terminal status — the row is simply never handled, so nothing surfaces in the logs beyond the row being picked up again each cycle.

Two consequences: - Wasted DB queries and poller work that compound as more such batches accumulate. - Output-file deletion is gated on `batch_processed`, so the batch's output and error files can never be deleted through the managed API.

**Expected:** once the poller observes a terminal provider status, the row is marked terminal (`batch_processed=true`) exactly once. A batch with no output file has no billable completion output, so it should be marked terminal *without* being bill…