Publishing several ids for one model is deliberate: an alias can stand for a
round-robin group, and a typed id coexists with the checkpoint it names. What
was missing is any way for a client to tell which ids are ONE model. Measured
on a live install: 206 published ids over 119 card entries -- 136 aliases, 20
absolute paths whose basenames were also listed, and 50 repo ids, with no exact
duplicates among them. A capability sweep walking that list reported seventy
"new models" it had not tested, all of them names it had already covered, and
had no way to know.

So each entry now carries:

  canonical_id  the same string on every id belonging to one model, so
                grouping by it is sufficient;
  alias_of      set ONLY on the non-canonical ids, so a client that skips the
                entries carrying it tests each model exactly once;
  aliases       on the canonical entry, the other names it answers to.

Two cards that share a checkpoint but differ in CONFIGURATION are not the same
model. They keep separate canonical ids and stay separate entries, because they
are two deliberately different setups and a client must be able to see both --
grouping them would hide one. A bare path only one of them can claim (ids are
unique in a listing) groups with the card that claimed it, which is the honest
answer: sending that path reaches that card's settings.

Nothing is invented. A canonical name that this listing filtered out -- parked
as disabled, or assigned to another engine -- is never pointed at; those ids
are left standing on their own rather than referred to a name the server will
not answer to.

_group_ids lives above the class, not between two methods: added there first,
it ended the class body, and 126 methods silently became module functions with
list_models among them. A test asserts it stays out.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC