[Feature]: Make large model catalogs navigable when building a route

[jasonpaulso]

[Feature]: Make large model catalogs navigable when building a route

Problem to solve

When a route member points at a provider with a large catalog (OpenRouter
currently lists a few hundred models), choosing a model in the route editor is
hard. The model picker presents the full list with no way to search or filter,
and the order appears to follow the upstream feed rather than anything a person
can scan, so finding a specific model means hunting through the entire list.
A related case: when someone specifically wants a no-cost option, there's no
quick way to narrow the list down to free-tier models.

Proposed behavior

Core outcome: let the person type to find a model in the route editor, matching
against both the display name and the model id (the ids are often what people
know, e.g. vendor/model-name), and present the list in a predictable order
when nothing is typed rather than raw upstream order.

Secondary outcome: a quick way to narrow the model list to free-tier options, so
someone assembling a low- or no-cost route doesn't have to recognize free models
by eye. How "free" is determined is a judgment call worth deciding deliberately —
provider naming markers are the easy signal, but they don't catch every case
(for example, a provider's "free models" router may not carry the same marker as
the individual free models), and response pricing would be more precise at the
cost of threading that data through.

Relevant context

• This is about the route editor's model selection specifically; provider
  selection is a short list and doesn't have the same problem.
• Applies wherever a keyed provider exposes a large catalog; OpenRouter is the
  clearest example today, but it's a general large-list problem, not
  provider-specific.
• Sort and search belong together — the ordering only matters because the list
  is long enough to need searching in the first place.

Safety check

• I searched existing issues for the same request.
• This request contains no credentials, OAuth data, account identifiers,
  email addresses, private prompts, or other sensitive information.