[Feature]: Support LiteLLM Responses-mode / chatgpt direct routes for custom providers

## QwenPaw Version

Observed on the current Docker installation from early June 2026.
I can provide the exact version/commit if needed, but the key runtime detail is that QwenPaw uses AgentScope's `OpenAIChatModel`, which currently calls `client.chat.completions.create(...)`.

## Description

When QwenPaw is configured with a custom LiteLLM provider (`chat_model: OpenAIChatModel`) and a model such as `chatgpt/gpt-5.4-direct`, delegated agent calls fail with:

`System messages are not allowed`

This happens even though the same LiteLLM route works successfully from LibreChat against the same LiteLLM instance.

After tracing the stack, the issue appears to be:

- QwenPaw custom providers backed by `OpenAIChatModel` always use `chat.completions.create(...)`
- the LiteLLM route for `chatgpt/gpt-5.4-direct` is marked as `mode: responses` / `litellm_provider: chatgpt`
- the route rejects the request shape QwenPaw sends, specifically because system prompt handling is incompatible
- there does not appear to be a Responses API-capable model class in the bundled AgentScope version, only `OpenAIChatModel`

These `chatgpt/*-direct` models are configured in LiteLLM as ChatGPT subscription/OAuth-backed direct routes (not OpenRouter, not a normal API-key OpenAI route).

They are reachable through the same LiteLLM instance and work correctly from LibreChat via that LiteLLM proxy.

The failure appears specifically when QwenPaw accesses the same LiteLLM route through its custom provider based on `OpenAIChatModel`.

So from the QwenPaw side this currently looks like:
- custom LiteLLM provider works for regular OpenAI-compatible routes
- but cannot use ChatGPT subscription/direct routes that need Responses-style handling

**Related PR(s):** none known

**Security considerations:** no direct security issue; this is a provider/model compatibility bug

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Environment

- **QwenPaw version:** current Docker deployment, early June 2026 build
- **OS:** Linux 5.10.110-rockchip-rk3588 (aarch64)
- **Install method:** Docker
- **Python version (if applicable):** 3.11 inside container

## Steps to Reproduce

1. Configure a custom provider in QwenPaw pointing to a LiteLLM proxy using:
- `chat_model: OpenAIChatModel`
- base URL like `http://:4000/`
2. Add/select a LiteLLM model route like:
- `chatgpt/gpt-5.4-direct`
3. Use that model in an agent with a non-empty system prompt (normal QwenPaw agent behavior)
4. Trigger a call, for example via delegation from another agent or directly in chat

## Actual vs Expected

- **Actual:**
QwenPaw fails with:
`litellm.BadRequestError: ChatgptException - {"detail":"System messages are not allowed"}`
and the delegated call aborts.

- **Expected:**
QwenPaw should either:
1. support Responses API-capable OpenAI/LiteLLM routes for custom providers, or
2. detect that the selected model/route cannot accept standard chat-completions + system prompt payloads and fail earlier/more clearly, or
3. offer a provider/model option that uses a Responses-compatible client path instead of always using `chat.completions.create(...)`

## Logs / Screenshots

Relevant stack trace:

```text
openai.BadRequestError: Error code: 400 - {'error': {'message': 'litellm.BadRequestError: ChatgptException - {"detail":"System messages are not allowed"}. Received Model Group=chatgpt/gpt-5.4-direct\nAvailable Model Group Fallbacks=None', 'type': None, 'param': None, 'code': '400'}}
```

QwenPaw stack shows it is using AgentScope OpenAI chat client path:

```text
File "/app/venv/lib/python3.11/site-packages/agentscope/model/_openai_model.py", line 327, in __call__
response = await self.client.chat.completions.create(**kwargs)
```

LiteLLM route used:

```yaml
- model_name: chatgpt/gpt-5.4-direct
litellm_params:
model: chatgpt/gpt-5.4
model_info:
mode: responses
litellm_provider: chatgpt
```
This route is a ChatGPT subscription/OAuth-backed direct route exposed by LiteLLM.

QwenPaw custom provider config:

```json
{
"id": "litellm",
"name": "LiteLLM",
"base_url": "http://10.10.23.1:4000/",
"chat_model": "OpenAIChatModel"
}
```

The same LiteLLM route works from LibreChat against the same LiteLLM server, which suggests the incompatibility is specifically in how QwenPaw/AgentScope accesses the route.

## Additional Notes

A few relevant observations from debugging:

- This does **not** look like a generic LiteLLM outage, because the model responds successfully from LibreChat.
- This does **not** look like a missing QwenPaw capability flag issue (`supports_multimodal`, etc.), because the core failure is request-shape / client-path mismatch.
- In the bundled AgentScope version I only found `OpenAIChatModel`; I did not find a separate Responses API model class.
- QwenPaw already has a learned capability cache for some model quirks (`needs_reasoning_content`, `rejects_media`), but nothing similar for models/routes that require Responses-style handling or reject system messages.
Important context:
- the failing models are `chatgpt/*-direct` routes exposed by LiteLLM
- these routes are backed by ChatGPT subscription / OAuth login on the LiteLLM side
- they are not OpenRouter routes
- they are not regular OpenAI API-key routes
- the same routes work correctly through LibreChat against the same LiteLLM instance
****

Possible directions:
- add a Responses-compatible model class / provider path for custom OpenAI-compatible providers
- support per-model client mode selection for custom providers
- detect `mode: responses`-style routes and choose a compatible execution path