Measured on a live pod. The pool gate from v0.3.91 worked —

    [lora] no adapters yet, but this engine serves a pool — starting with LoRA
           enabled so one can be added without a reload
    [vllm] launching: … --enable-lora --max-lora…

— and the adapter was still dropped:

    pod seeded expecting : sha256:2e820c…     (the local adapter directory)
    re-registered as     : sha256:b8eac366…   (an uploaded blob)
    orchestrator pushed  : b8eac366… ✓ 159 MB

The bytes arrived. The pod's CATALOGUE did not. It was seeded at boot with the
first id, /v1/loras/register repointed the entry at the second, and nothing
told the pod — so its engine looked for an id nobody holds, dropped the
adapter, and served the base under its name. (The bundle hash is deterministic;
the two ids differ because the adapter genuinely changed, not because hashing
is unstable.)

Two keys missing a version, the same shape as every other bug in this area:

  * _ensure_adapters sent the BYTES only. It sends bytes and entry now.
  * teach_model keyed "already taught" on (pod, model), so a re-register could
    never reach a pod it had spoken to once. Keyed on the adapter's source.

/v1/loras listed only the TRAINING registry, so an adapter that arrived by
upload+register was invisible there — a successful registration looked exactly
like a failed one, which is how this was found. It lists both now, tagged
`trained` or `registered`, with the adapter id, base and pool.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HXRMe9ZPUQCCCtBai9uqt3