Summary

This PR replaces smart model resolution in pi-teams with a stricter, more explicit model-selection workflow.

The main changes are:

• add list_available_models so the orchestrator can see real, currently available models from the pi runtime
• require fully qualified provider/model values when a model is explicitly provided for new teams or new teammates
• fail fast for unknown or unqualified explicit model names instead of trying to guess what the user meant
• use pi settings only to influence ordering/preferences in model selection output, not to silently rewrite explicit model choices
• use ctx.modelRegistry.getAvailable() in-process instead of shelling out to pi --list-models
• if a model is omitted, fall back to the current active model (or team default model when present)

Why

I ran into problems immediately while trying to use pi-teams in a normal workflow.

In particular, ambiguous model names like gpt-5 could end up resolving to providers the user did not intend, including providers that may cost money or fail due to missing auth. That made the old smart-resolution behavior feel too magical for a workflow that directly affects cost, reliability, and user expectations.

This change tries to make the workflow better across the board by making model choice:

• explicit when explicitly requested
• inspectable
• validated against what is actually available in the running pi session
• consistent with the user’s currently active model when no explicit override is given

Final behavior

For newly created teams / newly spawned teammates:

• users (or the orchestrator model) can call list_available_models
• then choose a fully qualified provider/model
• unqualified names like gpt-5 or haiku are rejected when explicitly provided
• unknown fully qualified models are rejected

If no explicit model is provided:

• team_create uses the current active model
• spawn_teammate uses the team default model, or else the current active model
• create_predefined_team uses the current active model when no explicit default_model is provided

For pre-existing team configurations:

• nothing new needs to be inferred
• if the config already has explicit models baked in, that continues to work as-is

Important note

I want to be explicit that this PR includes a fairly opinionated workflow change, and I made a number of product/design decisions here without prior discussion.

Please treat this as a contribution you can adopt, adapt, partially use, or decline entirely.
If this direction does not fit the project, that is completely fine — in that case I will simply maintain the behavior I need in my own fork.

Notes on implementation

• available models now come from ctx.modelRegistry.getAvailable()
• user preferences still come from pi settings (defaultProvider, defaultModel, enabledModels) and optional pi-teams config ordering
• the listing tool already sorts results with preferred models first
• the omission/default behavior now lines up well with the intent behind PR fix: prevent LLM from overriding pi's default model in subagents #20, while still keeping explicit model selection strict and validated

Validation

• npm test
• manually verified in pi that:
  • bare explicit models are rejected
  • list_available_models returns real runtime models
  • explicit fully qualified models work
  • omitted models fall back to the current active model

Changelog

• intentionally left untouched