a pod that cannot run the pipeline is not a failed page (v0.4.2)

0.4.1 sent pages to the pods, as it was meant to. The pods answered 503:

    model 'datalab-to/surya-ocr-2' is not served over HTTP by this
    install, so an OCR engine cannot attach to it

_read_on_pods raised that, so the document failed -- while the local
pipeline sat there perfectly able to read it. The method's own docstring
already said "an optimisation that cannot run must cost latency, never an
error"; only the "no pod at all" case implemented it.

A refusal (404/501/503 from the pod's own /v1/ocr) is now a fallback, not a
failure:

* the rest of the document stops being sent one failure at a time;
* the pool is set aside for 300s, so the next document does not pay a
  failed round trip per page, and a rebuilt image is picked up without
  restarting the orchestrator;
* it is said ONCE, in the pod's own words, and says that this box will now
  rasterise so its memory is worth watching.

A 400 still fails: falling back on any error would hide a broken page
behind a slow one.

This restores service. It does NOT make the pods run the pipeline -- that
is the next commit, and the log line above is what will say when it works.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM