### Check for existing issues

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

### What happened?

`CheckBatchCost` has no per-job failure isolation. A single batch whose cost calculation raises aborts the entire polling cycle, so every other batch selected in that cycle is never reconciled and never billed — `batch_processed` stays `false` for all of them.

Because the failing batch is re-selected on the next cycle too, this does not clear itself. One bad batch stalls managed-batch reconciliation indefinitely for every user on the deployment.

**Expected:** a failure while reconciling one job is contained to that job — mark it failed, record the error, and continue to the next job in the cycle. One poisoned batch should not be able to block unrelated batches from being billed.

A batch that reaches `completed` with no output file is one easy way to produce the raising job (see #33987, which was filed separately for the exception itself) — but the isolation gap is independent of what causes the exception.

### Steps to Reproduce

1. Run a DB-backed proxy with managed files/batches enabled (`/v1/files` and `/v1/batches` returning `litellm_pro…