Route dynamically discovered models through their compatible API protocol

[yourcasualdev]

Problem

The connector currently assigns one provider-level AI SDK package to every model discovered from CLIProxyAPI. Mixed catalogs can contain both OpenAI-compatible and Anthropic-compatible models, so Anthropic-compatible models such as those returned with owned_by: anthropic are incorrectly sent to /v1/chat/completions instead of /v1/messages.

This causes valid OpenCode Go models to fail and can trigger account suspension in the pool after upstream authentication errors.

Reproduction

1. Configure CLIProxyAPI with a mixed model catalog.
2. Run opencode models cliproxyapi and select a model whose catalog owner/provider is Anthropic-compatible.
3. Send a prompt.
4. Observe CLIProxyAPI receives POST /v1/chat/completions rather than POST /v1/messages.

Expected behavior

• Discover models from CLIProxyAPI without maintaining a hardcoded model list.
• Resolve protocol dynamically from model/provider metadata.
• Use @ai-sdk/anthropic and /v1/messages for Anthropic-compatible models.
• Preserve the configured default protocol for other models.
• Keep discovered models usable if the external metadata catalog is unavailable.
• Preserve user model customizations without losing discovered routing metadata.

Acceptance criteria

• No Go model IDs are hardcoded.
• Both provider-level and model-level protocol metadata are supported.
• Tests cover mixed-protocol catalogs, metadata failure fallback, and merged user customization.
• A local OpenCode smoke test confirms Anthropic-compatible models hit /v1/messages and OpenAI-compatible models continue to work.