Configuring the Digesta catalogue on the production orchestrator turned up three
faults in warm_configured_pools, all of which spend money:

  * `enabled: false` was not consulted. A catalogue entry parked for later with
    keep_warm still set rented a GPU at every boot.
  * the entry was named `alias or path`. A RunPod-only entry has neither — no
    weights live on that machine, and an alias only exists when a second name is
    wanted — so it warmed under the key "" and the pool was never the one that
    went on to serve requests. `id` is now the fallback, and an entry with no
    name at all says so instead of warming nothing quietly.
  * the schedule was ignored. ensure_ready() is the "a request is waiting" path
    and provisions unconditionally; at boot nothing is waiting, so a restart at
    02:00 on a Sunday rented exactly the pod the window exists to avoid. It now
    checks effective_min_pods first, which also means a client lease that
    outlives a restart is honoured rather than dropped.

Found on the host, not by reading: the warm pod the configuration asked for
never appeared.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>