`pod_ocr_engine` rewrote EVERY whole-request OCR forward to docTR. The premise
was that a pod image cannot carry a VLM's model server, which was true of
`coderai-vllm` and never true of `coderai-vllm-ocr`: that image carries surya,
the rasteriser and its own vLLM -- it IS the pod-side pipeline -- and it
carries no docTR at all, which is why its pods launch with
CODERAI_OCR_FALLBACK_ENGINES=off.

So the rewrite asked a pipeline pod for the one engine it cannot possibly have,
and the pod answered "OCR engine 'doctr' is not enabled". The question cannot
be asked without the image, and the gateway was not passing one.

Found by sending a page through a pod, not by reading the code: the id
resolved, the pool provisioned, the pod booted and went ready, and the request
still came back 400 naming an engine nobody had asked for.

A named configuration (ocr.engine_configs) also resolves to its base engine
here. The ids are an orchestrator-side naming layer and a pod is a
pre-configured instance of one -- its env already carries the overrides -- so
telling it the id names an engine it has never heard of.

Omitting the image keeps the old answer, so callers that cannot know it are
unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66