Re-registering an adapter updated the catalogue and the pod went on serving the
OLD weights. Two caches, neither of which had a version in its key:

  * the orchestrator remembered "this pod already has this adapter" by NAME, so
    the new bytes were never sent;
  * and the engine was asked "do you serve this name?" — which a stale adapter
    answers yes to. It kept what it was launched with.

So the update looked applied from every angle a client can see: the catalogue
had the new blob, the name worked, the request succeeded. The only symptom was
output identical to the previous version, which is exactly the symptom nobody
can see from a 200.

Both are keyed on the adapter's SOURCE now. When it changes, the bytes are
pushed, the old adapter is unloaded from the running engine and the new one
takes its name — no reload of the base model, nothing else on the pod
disturbed. When the swap cannot be done in place the engine is restarted with
the new adapter, and says which it is doing.

An engine coderai holds no record for is never treated as stale: unloading an
adapter on a guess is worse than serving the one that is there.

Content-addressed versioning is what makes this safe to run on every retrain —
bytes that have not changed are recognised as the same adapter and nothing
reloads.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HXRMe9ZPUQCCCtBai9uqt3