Add LLMTR as an LLM provider

### What feature would you like to be added or updated?

Add [LLMTR](https://llmtr.com) 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:

```bash
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:

```json
{"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.

Start by reading OpenAICompatibleClient and the Responses API message translation in ollama_client.py. Inspect LLMTR's public GET /v1/models catalogue and the existing provider environment-variable resolution. Done means chat and responses-only models route to their supported endpoints, while non-chat models are rejected clearly without exhausting retries.

Written by the indexing model from the issue text.