`runpod.image` is optional. Naming `engine: coderai-vllm-ocr` is how the
image is chosen, and pod_plan resolves that at launch. But the OCR
pipeline's "do these pods rasterise for themselves" gate read the RAW
`image` field, which is empty in exactly that configuration, and concluded
the pods could not run the pipeline.

So a deployment renting A40s with the surya venv and pypdfium2 baked in ran
the whole pipeline on a GPU-less orchestrator instead: 4 rasteriser
processes, 8 surya workers, and ~120 documents each holding a 32-page
bitmap window. 47 GB resident on a box with 1 GB free and its swap full.
Nothing failed. The pods served the model, the pages came back, and the
only symptom was memory.

Two readings of one switch, applied to different inputs:

* pod_image_for_entry() is now the single resolver, and pod_plan() uses it
  too, so neither side can drift from the other.
* the gate SAYS which side of the line it landed on, once per answer, with
  the image that decided it and how to change it. Silence was the real
  cost here -- the local path is a complete, successful read, so an
  install could be configured for the pod-side pipeline, never once run
  it, and look exactly like it was working.

A lookup that throws now reports itself rather than answering "no".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM