A pool configured max_pods=1, min_pods=1 held two A40s: a pod adopted at
17:41, a restart at 17:43, a second pod rented at 17:46. $1.18/hr for a
configuration that asked for $0.59, and the operator's explicit ceiling
exceeded by the very code path whose job is to hold exactly one pod warm.

The warm-floor top-up in maintain() computed

    in_hand = len([p for p in self.pods if p.healthy]) + self._booting

and tested BOTH the deficit and the max_pods cap against it. After a restart
the pool adopts the pod it had before. That pod is briefly not yet healthy, and
it was not booted by this process, so `_booting` is 0 and `in_hand` is 0 --
room under a cap of one, beside a pod that is already running and already
being charged for by the minute.

They are two questions and they need two counts. The deficit is in pods that
can SERVE, so it keeps counting healthy ones: an unhealthy pod does not satisfy
a warm floor whose entire purpose is that the next request finds a pod ready.
The cap is in pods that are CHARGED FOR, so it counts every pod in the pool
whatever its health -- which is what `_should_grow` has always done for its own
cap. This path disagreed with it, and the disagreement was the bug.

The existing test pinned the single `in_hand` by its source text; it now pins
both counts, including that the cap is the billing one, since that is the part
whose regression costs money.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM