/v1/models re-reads models.json on every call, but the loader's alias map is
built ONCE at startup. So an entry added while the server runs is advertised
immediately and cannot be loaded at all: the alias resolves to nothing, the
raw alias reaches diffusers as a repo id, and the caller gets

    Repository Not Found for url https://huggingface.co/api/models/<alias>

-- a 401 against HuggingFace for a model sitting on the local disk.

Measured today registering Wan2.2-TI2V-5B: weights cached, `path` correct,
and the request failed that way; the SAME model requested by its path loaded
immediately, which is what pinned the cause to the alias map rather than the
entry or the weights. The pre-existing Z-Image alias, updated rather than
added, worked throughout -- that contrast is the whole diagnosis.

This is the fifth instance of one pattern in this codebase: a name in
models.json not matching the name the runtime registered. v0.5.4 read a
backend from the wrong map, v0.5.5 looked for a binary where it does not live,
v0.5.7 published an id that resolved to nothing, the LTX pair shared one path
between two entries, and now the listing advertises what the loader cannot
resolve. A cross-cutting identity-resolution audit is still the right fix; this
is the narrow one.

An alias the map has not seen is now looked up in the config itself and cached.
A parked entry is deliberately NOT resolved -- parking is how an entry waits on
a blocker, and resolving it would hand clients a model that answers 500.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZnmWyKjWZerwsb27jZ