Add LLMTR as an LLM provider

What feature would you like to be added or updated?

Add LLMTR as a first-class model provider, alongside the existing OpenAI, Anthropic, Azure, OpenRouter, Doubao, Ollama and Google providers.

LLMTR is an OpenAI-compatible AI gateway that serves Türkiye-hosted models (Trendyol Asure, Muse Glimmer, and other Turkish-language models) next to global models from OpenAI, Anthropic, Google, xAI, Qwen, Mistral, DeepSeek, Moonshot, Z.ai and others, behind a single API key. Model ids use an owner/model form, e.g. anthropic/claude-sonnet-5 or llmtr/trendyol-asure-12b.

Usage would look like:

trae-cli run "Fix the bug in main.py" --provider llmtr --model "anthropic/claude-sonnet-5"
trae-cli run "Kodu Türkçe yorumla"    --provider llmtr --model "llmtr/trendyol-asure-12b"

Why do you need this feature?

Configuring LLMTR through the existing openai provider with a custom base_url mostly works, but it breaks down on one important detail: LLMTR's catalogue spans two endpoint families.

Of the 237 models it currently serves:

• 172 speak /v1/chat/completions
• 15 speak only /v1/responses — including openai/gpt-5.3-codex, openai/gpt-5.5, openai/gpt-5.6-* and the whole xai/grok-4.x family
• 50 are non-chat models (embeddings, images, video, audio, rerank)

OpenAICompatibleClient only speaks chat completions, so the responses-only group — which contains several of the models a coding agent would most want — cannot be reached at all today. Pointing the openai provider at them returns:

{"error": {"message": "Model \"gpt-5.3-codex\" requires the /v1/responses endpoint instead of /v1/chat/completions.", "type": "endpoint_mismatch"}}

and the non-chat models fail only after the full retry loop has burned through its backoff.

A dedicated provider can read LLMTR's public model catalogue (GET /v1/models, no API key required) and route each model to the endpoint it actually supports, reject non-chat models up front with a clear message, and pick up LLMTR_API_KEY / LLMTR_BASE_URL through the existing provider env var resolution.

Additional information that you believe is relevant to this feature request

I have an implementation ready and will open a PR referencing this issue. It reuses OpenAICompatibleClient unchanged for the chat completions route, and mirrors the Responses API message translation already used by ollama_client.py for the responses route. It adds no new dependencies — the catalogue is read through the openai SDK that is already a dependency.

Similar provider requests for reference: #247, #421.