Two paths append pods -- a fresh rent and an adoption -- and neither checked
whether the pod was already in the pool. On a restart both fire for the same
machine within the same second:

  [runpod] adopting pod j74fxkxr9vs3fg's bearer token
  [runpod] reclaim: took back a pod for 'datalab-to/surya-ocr-2' ...

and the pool then held one A40 twice. Every capacity question is answered by
walking self.pods, so the duplicate is not cosmetic:

* the pool claimed 2 x max_inflight_per_pod = 128 slots on a card that was
  serving 31, reporting "2 in pool, 2 healthy, 2 at cap" with 255 pages
  queued -- and refusing work the pod could have taken;
* max_pods is enforced against that same count, so a cap of ONE was satisfied
  by two entries for one pod, which is how a second real pod came to be rented
  beside it and billed at $1.18/hr for a configuration that asked for $0.59;
* the in-flight staleness sweep added in 0.4.28 cannot help here, because both
  entries hold legitimate fresh timestamps. A duplicate is not a leak.

Both sites now go through `_add_pod`, which is the only remaining way into the
pool and refuses a pod id it already holds. The EXISTING handle is kept rather
than replaced: it carries the in-flight accounting for work already dispatched
to that pod, and dropping it would strand every slot it holds. What can
legitimately change is refreshed onto it -- the address, since RunPod remaps
ports and the pod id is the identity, not the url.

A test asserts there is exactly one `self.pods.append(` in the file: the guard
is worth nothing if a third path is added later that bypasses it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM