[Feat] Apply provider-recommended model defaults in setup and settings

[mrubens]

Summary

Replaces the single generic model default with provider-specific recommended defaults per model role. Each inference provider in the setup catalog can now declare recommended models for the non-coding roles (helper, vision, code review, explore, planning); the coding recommendation is always the provider's existing defaultRoomoteModel, so there is one source of truth per slot.

• Data structure: an optional recommendedRoleModels map on each SETUP_MODEL_PROVIDER_CATALOG entry, plus a shared buildRecommendedDeploymentModelConfig() resolver. Roles left unset mean "same as coding", so single-model providers get a valid recommendation by omitting the field entirely. A catalog test enforces that every recommended id is in that provider's suggestedTaskModels.
• Setup flow: connecting a provider in the setup wizard now persists the full recommended role split instead of only the coding model. The existing recommended-model auto-add already seeds these models into the catalog.
• Settings: a "Use recommended" action on the Default Models card re-applies a connected provider's recommendations at any time (direct button for one connected provider, a small picker for several). It is implemented client-side through the existing draft/autosave flow — no new tRPC route — and it adds/enables missing recommended models, resets unset roles to "Same as coding model", and skips env-managed roles.

The recommendations follow one pattern: a fast low-cost model for helper + explore, the provider's default coder for coding, and a strong reasoning model for code review + planning. Vision is only set explicitly when the recommended coding model is not known to be multimodal (currently just OpenCode). Google Vertex AI now mirrors the Anthropic/Bedrock split (Claude Sonnet 5 coding default, Haiku 4.5 helper/explore, Opus 4.8 review/planning). Mappings are deliberately easy to edit in code.

Requesty is hidden from new connections via a new hidden catalog flag: it no longer appears in the setup wizard or settings connect surfaces unless already connected. The catalog entry stays registered, so existing Requesty deployments keep working (model-id resolution, credential env-var forwarding, labels, and managing/deleting the saved key). The setup wizard's provider picker now renders from the server-filtered status list instead of the raw catalog to support this.

Intentionally not built (future preset system can layer on top of RecommendedRoleModels): saved user presets, a preset picker at task start, or any multi-level preset management UX. This behaves as an apply-once macro.

Test plan

• New types tests: resolver behavior (mapped provider, fallback-only provider), the suggested-catalog membership invariant across all providers, and hidden-provider filtering in buildSetupModelStatus (excluded when unconnected, listed when connected).
• New UI tests: single-provider apply from the header action, multi-provider picker, and env-managed roles staying untouched.
• Existing suites green: packages/types (556), settings components + setup step + task-models and setup-new commands (450), model-runtime-config (20).
• pnpm lint, pnpm check-types, and pnpm knip all pass.

Note: saveSetupNewModelConfigCommand's wiring has no direct test — the command isn't covered by the existing setup-new test harness and the change is a one-line delegation to the unit-tested resolver.

Docs: added a "Recommended default models" section to apps/docs/models.mdx; removed Requesty from the provider lists in models.mdx and the README.

[roomote-roomote]

No new code issues found. See task

• packages/types/src/model-provider-config.ts:384 Surface the Vertex Claude enablement and region prerequisites before automatically selecting Claude. The new default and role mappings are persisted as soon as valid Vertex credentials are saved, but the catalog itself notes that Claude may require separate Model Garden enablement and setup currently gives no user-facing warning. A project can therefore complete setup and fail on its first model call; add credential help for the prerequisite (including location availability), verify access during setup, or retain a generally available default.

_{Reviewed 2c393ac}

[mrubens]

Addressed the Vertex Claude prerequisite finding in c0387ee:

• Added credentialHelp to the Google Vertex AI provider pointing at Model Garden enablement and location availability, with a link to the Model Garden console. It renders below the credential input on both connect surfaces.
• The setup wizard now renders provider credentialHelp — previously it only rendered in Settings > Models, so this guidance (and Amazon Bedrock's existing region note) never appeared during onboarding, which is exactly where the recommended defaults get applied. Covered by a new setup-step test.

Two parts of the finding we're deliberately not taking:

• Keeping Claude as the Vertex default — this is an intentional product decision; the defaults are meant to recommend the strongest fit per provider, and the new inline guidance makes the prerequisite visible before connecting.
• Verifying model access during setup — a connect-time probe would be a new mechanism with its own failure modes (IAM list vs. invoke permissions, region mismatches), so it's out of scope for this PR and noted as possible follow-up.