0.4.10 fixed `_served_names` and left `_sibling_lora_specs` reading
`text_models` only -- found while verifying the built image, which is the
point of verifying the built image.

That second function decides which adapters vLLM registers AT LAUNCH. So a
QLoRA declared on a `vision_models` entry was never collected when a text
request started the engine: vLLM came up with no `--enable-lora`, and then
answered under the adapter's name with BASE weights. Nothing failed, nothing
was logged, and the reply looked exactly like a reply from the adapter. Its own
docstring records that happening once already, for the sibling reason.

Both reads are now one `_catalogue_entries()`: every section, one reader, so a
third caller cannot drift from these two. A test asserts
`md.get("text_models")` appears nowhere in the module.

Also pinned, because it decides what a client must ASK for: an entry that owns
an adapter registers it under `_entry_name`, which prefers `alias` over `id`
(a seeded pod entry carries an alias and no id). An entry with BOTH therefore
splits -- the alias serves base+adapter, the id serves the bare base, and
nothing says so. An entry that owns an adapter should carry ONE name, which is
how diogene-alpha and digesta-alpha were already declared and is now how the
qwen38 vision entry is too.

13 tests. 3358 passed, 13 pre-existing failures (broker, studio, manual
client) untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM