The root cause under four releases of "the adapter is not applied". Measured on
a live pod:

    catalogue says       : sha256:b8eac366…   (hash of the tar a client sent)
    this bundler's own   : sha256:2e820c…     (same content, its own packing)
    pod lookup b8eac366  : 404
    pod upload returns   : {"id":"sha256:2e820c…","existed":true}

`save_lora_blob` stored an uploaded bundle under the hash of THE BYTES THAT
ARRIVED. A tar of one adapter made by GNU tar, by this bundler, or by anything
else hashes differently — mtimes, ownership, member order — so the id recorded
in the catalogue was one nobody else could reproduce. Every later push
re-bundled the unpacked directory, stored the canonical id, and the pod looked
up the uploaded one and found nothing. It had the bytes the whole time, under
another name, so it loaded the base model and answered under the adapter's
name. Fluently, with nothing in the reply to say so.

An uploaded bundle is now unpacked FIRST and stored under the id of this
bundler's packing of it, which is what every side computes. /v1/loras/upload
returns that id, so what a client registers is what a pod can resolve.

This is also why it took four attempts: the engine flags, the seeding and the
entry propagation were each genuinely broken and each fix was real, but
underneath them the two sides were never going to agree on the id.

_load_lora_runtime had two bare `return False` paths — no adapter spec, or an
id the blob store cannot resolve — which is exactly why this hid for three
releases while every other layer was examined. Both say what happened now, and
the second says the thing that matters: the catalogue and the store disagree
about this adapter's id.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM