Composer model picker lists models for providers with no configured key

Problem

The composer's model dropdown lists models for providers the user has not configured. Configure only Gemini (no OpenAI key), add a Gemini model, and the picker still shows gpt-5.5, gpt-4o, gpt-4o-mini, o3-mini, deepseek-chat alongside your Gemini models. Selecting one of those just fails on first send (no key), and for a non-technical user it's confusing clutter — "why are all these models here when I only set up Gemini?"

Root cause

The curated model list is seeded with the hardcoded OpenAI defaults regardless of which provider is actually configured:

• SessionManager.KNOWN_MODELS is OpenAI-only (platform/coworker/server/manager.py).
• _curated_models() falls back to KNOWN_MODELS when prefs has no list, and add_model() seeds the list with KNOWN_MODELS the first time any model is added — so adding a single Gemini model inherits five OpenAI/DeepSeek entries.
• get_settings() returns that list as models, and the composer (platform/surfaces/gui/src/components/Composer.tsx) renders it verbatim.

So a Gemini-only user ends up with a picker full of models they have no key for.

Proposed fix

Show only models whose provider is actually configured (has a stored/env key, or Ollama is reachable), always keeping the active default model selectable. This can be done either:

• backend — filter in _curated_models() / get_settings() against configured providers, or
• frontend — filter the composer options in Composer.tsx using the already-available provider state from getProviders().

Small and additive; the conservative default for a fresh OpenAI user is unaffected.

Relation to #328

This is a focused bug fix for the composer picker, not the broader generic provider/model config redesign in #328 — it can land independently, or fold into that effort if you'd prefer to handle it there.

Offer

Happy to open a PR for whichever layer you prefer (I'd lean toward the backend filter so every surface benefits). Want me to send it?