Two faults, one cause: `local` was both the default and the only engine mode
that would quietly settle for the CPU.

Surya's own settings pick the device and fall back cuda -> mps -> cpu
(surya/settings.py TORCH_DEVICE_MODEL), so `local` on a machine with no CUDA
ran a VLM pipeline on the processor: minutes a page, a result that looks
perfectly normal, and nothing anywhere saying why. paddle and docTR already
refuse in exactly that situation — surya was the exception. It now refuses too,
with a 503 that names both ways out, and the worker is TOLD its device rather
than left to guess. Detection fails closed: torch is asked first (it is what
surya will ask), nvidia-smi second, and if neither can answer the answer is no.

And `surya_serve` no longer defaults to `local`. An install that said nothing
got the one mode that runs the model on this box — on a GPU-less orchestrator
whose whole job is renting one, that is the worst possible default. It now
defaults to `model`, which adapts to wherever the checkpoint is served and asks
for surya_model_id when it has not been told. Safe to change: both production
installs set the mode explicitly (`model` on Aruba, `vllm` on zeiss), so
nothing was relying on the old default.

Running on the CPU is still fully supported — surya_use_gpu = false — it just
has to be a decision now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW