runpod: a region and a warm-pod schedule per model, spend over the API (v0.2.82)

Three gaps, all configurable from the model page:

- data_center pins a model's pods to one RunPod region. Precedence is
  volume > model > account: a pod in another region cannot attach the
  volume, so the volume still decides.

- schedule_enabled/start/end/days/tz gate the WARM FLOOR only. Outside
  the window the floor is 0 and the warm pod is released without waiting
  out idle_timeout_s; a request arriving out of hours still cold-starts
  one, exactly as min_pods=0 always has. An end before the start runs
  overnight and belongs to the day it started on. An incomplete or
  unparseable window is treated as no schedule rather than a floor of
  zero, and an unknown time zone falls back to local, not UTC.

- GET /v1/runpod/spend serves the pods, ledger, caps and schedule status
  to an API key marked admin, so an external monitor can poll spend
  without an admin session. Opt-in per token; an ordinary key gets 403.

pools_schedule_status() reports in_window/next_change/effective_min_pods
on /admin/api/runpod/stats and on the new endpoint.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>