docs: the orchestrator is the FULL image — a capability image is a pod

The guide told the operator to install ghcr.io/nextime/coderai-ocr as the
orchestrator. That is backwards and it is the mistake the Digesta bring-up
actually made: a capability image is a POD, what CoderAI rents and launches,
and it has no GUI; its admin pages are not behind the API's bearer check, so
it is not something to expose either.

Rewritten around the full image on port 8776, with the two settings a
GPU-less host needs and the reason each one is needed:

- backend.type must be "cpu", not "auto": with auto, main.py searches
  nvidia/vulkan/opencl and exits "No supported backend detected" when it
  finds none. Set explicitly, that search is skipped.
- engine_specs must name the engine: left to auto-detect, the front creates
  a no-GPU engine NAMED cpu but launches it with backend="auto"
  (engine_supervisor.py:311), which hits the same abort whatever
  backend.type says. That is why the log reads "[cpu] Available backends:
  {'cpu': True}" and then "No supported backend detected" — [cpu] is the
  name, auto was the backend.

Also states that server.engines=0 means AUTO (one per GPU, min 1), that no
"zero engines" setting exists, and that you do not want one: the RunPod
pools, scaler and reaper live inside the primary engine, so one idle CPU
engine is the component that manages the pods, not a workaround.

Service examples, the upgrade section and the reference table all follow.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>