A speaker pod reported EXITED with uptime 0s from its very first poll. The loop
waited out the full budget on it — three machines in a row — printing 'image
pull in progress', which it never was: wait_ready treated only TERMINATED and
FAILED as terminal. EXITED past a short restart grace now fails fast and says
what it means: the image pulled and the process died on boot.

The budget it waited out was 300s, not the 900s set on the pool class: the
dataclass default was never updated. Two numbers for one thing, and the smaller
one silently won. There is one now.

Why the process died: boot.sh ran under set -u, and every line before the exec
is a diagnostic — it exists to describe the pod, and a diagnostic must never be
able to stop the boot it describes. The image boots fine locally; on RunPod an
environment difference tripped a strict-mode abort before uvicorn was reached.
That is the best-supported explanation, not a proven one — RunPod publishes no
log API to confirm it — so the script is now unable to abort before its exec
under any environment, verified against a bare sh with nothing set.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY