A request for LTX-2.3-10Eros loaded LTX-2.3-PinkCherry: a different 15.9 GB
transformer, silently, and from an entry that was DISABLED.

self.config is keyed <kind>:<model_name> where model_name is the weights path,
so entries sharing a path clobber one another and only the last survives. That
is not a corner case -- it is how one base checkpoint is served under several
configurations: lisa / lisa-32k differ only in context length, 10Eros /
PinkCherry only in which GGUF is their transformer. PinkCherry comes second in
models.json, so it won, parked or not.

The VRAM estimator already disambiguated this way, by the id the caller asked
for, after lisa-32k was once sized at lisa 51.97 GB. The config used to LOAD
the model did not. Now both do:

* every type setter stores a config under its ALIAS as well as its path, so a
  sibling is reachable by the only name that distinguishes it. The path key
  keeps its old meaning (last writer wins) for callers that know only a path.
* _config_for_model_key takes the requested id and prefers the entry whose
  alias matches.

Applied to all eight setters rather than video alone -- the collision is the
same for audio, image and embedding, and fixing one type is how this survived
being found twice already.

Also: build_gguf_pipeline_components passed `model_name` as the diffusers repo
supplying the component configs. Once siblings became reachable by alias that
can BE the alias -- "LTX-2.3-10Eros", not a repo -- and from_single_file
rejects it. The repo is whatever the entry names in `path`, every time.

Verified live: LTX-2.3-10Eros now loads its own transformer and the pipeline
assembles, 8/8 components.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZnmWyKjWZerwsb27jZ