2026-10-20, qwen38: a restart generated a fresh random pool token (none is
configured), adopted a pod still carrying the old one, and rented a second pod
with the new one. A pool has one api_key, so whichever token it held answered
401 on the other pod — "Invalid API key" on every request until both pods were
destroyed. The adoption guard ("only swap while we hold no pod") could not
help: the rent and the adoption happened in the same minute.

- PodHandle.api_key: the token THIS pod was launched with, or adopted
  carrying. pool.pod_key(pod) resolves it, and the pool remembers the tokens
  of pods it no longer holds so a quarantined one stays reachable.
- Adoption keeps the adopted pod's token on that pod instead of replacing the
  pool's, so pods with different tokens coexist.
- _acquire_endpoint returns (base, release, bearer): the key is handed out
  WITH the address. Reading it afterwards from the pool was wrong twice —
  the pool's token could change mid-acquire, and _last_pod is one attribute
  shared by every concurrent request, so it could name another request's pod.
- The OCR worker's majority vote over the registry's keys is gone; each pod's
  key rides on its own handle.
- The pool's own token is minted once and persisted beside the pod registry
  (0600), so a restart no longer orphans every pod it had rented. A
  configured api_key still wins, and an unwritable directory still serves.

Also tried and reverted: treating an orphaned mid-boot pod as "on the way" to
stop a restart renting beside it. That reintroduces the twenty-minute freeze
of test_runpod_restart_orphans. Renting twice costs cents; a pool that will
not rent serves nothing. The reasoning is recorded in sibling_is_provisioning.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM