The RunPod page learned to show pods nothing here rented -- another host on
the same account, or a pod whose registry entry was lost -- and the only thing
it could do with one was terminate it. For a pod that is healthy, already
rented and already billing, that is the expensive answer: it throws away a
card and a 6-14 minute boot that have both been paid for, and under a warm
floor the pool then rents a replacement and pays that boot again.

The blocker was always stated as "it needs the pod's bearer, and get_pod()
does not select env". That was half wrong. pod_plan writes the token to TWO
places, and the one that matters most is not the environment: vLLM and
llama.cpp take it as --api-key, so for them it is in the pod's ARGS. Only a
coderai pod reads it from the environment. Both are recoverable from the pod's
own launch, so get_pod_launch() asks for exactly that -- on a path of its own,
with one caller, because get_pod/list_pods rows are rendered on the admin page
and logged, and a token that reaches either is a token leaked.

Adoption then goes through the REGISTRY rather than inserting a handle into a
pool: the entry is written with its owner cleared, and the pool's own survivor
sweep takes it through find_shared_pod. So the image check, the card check, the
health probe and the per-pod bearer are the ones already in use everywhere
else, and an adoption that should not happen is refused by the code that
refuses it everywhere else. If no pool ever takes it, the heartbeat goes stale
and the reaper collects it -- the right end for a pod nothing here can serve.

The hazard that keeps `force`: a pod named for another deployment may still be
MANAGED by that deployment. Two controllers on one pod each dispatch to it,
each miscount its in-flight work, and either may terminate it under the other.
Nothing RunPod reports says who is managing a pod, so it cannot be detected --
only refused by default, with the reason said in full, and overridden by an
operator asserting what the API cannot tell us. PodNotOursError carries that
distinction structurally, because the other refusal on the same endpoint -- a
pod no token can authenticate -- must NOT be re-offered with force.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>