Pre-submission Checklist / 提交前检查

• I have searched the existing issues and this feature has not been requested / 我已搜索现有 issues，此功能尚未被提出
• I have read the documentation / 我已阅读文档

Problem Statement / 问题描述

在使用 Coding Plan 等高频调用场景时，当多个请求同时命中同一个供应商（如 OpenAI、Anthropic 等），容易触发供应商的 Rate Limit（429 错误）。目前的负载均衡主要解决"选哪个渠道"的问题，但缺乏对"同一渠道并发数"的控制。

具体案例：
我将 Kimi Code 接入 AxonHub 后，频繁遇到以下错误：

failed to stream request: Request failed: Too Many Requests, 
error: The engine is currently overloaded, please try again later, 
type: api_error

错误发生在并发请求较多时，即使单个请求的 token 量不高，也会因为短时间内请求数过多而触发供应商的限流。目前只能通过客户端重试来缓解，但无法从根本上解决问题。

问题表现：

• 短时间内大量请求打到同一供应商 API
• 频繁收到 429 "Rate limit exceeded" 或 "engine overloaded" 错误
• 影响用户体验，需要客户端自行实现重试和退避逻辑

Proposed Solution / 期望方案

为每个渠道/供应商增加请求排队（Queue）和并发限制（Concurrency Limit）机制：

1. 并发数限制：为每个渠道设置最大并发请求数（如 max_concurrent: 5）
2. 请求队列：当并发数达到上限时，新请求进入队列排队，而不是直接发送到供应商
3. 队列超时：设置队列等待超时时间，超时后返回友好错误信息
4. 动态调整（可选）：根据响应中的 Rate Limit 信息动态调整并发阈值

配置示例：

channels:
  - name: kimi-coding
    provider: kimi
    concurrency_limit: 5        # 最大并发数
    queue_size: 100             # 队列最大长度
    queue_timeout: 30s          # 队列等待超时

Alternatives Considered / 备选方案

• 在客户端实现退避重试：增加了客户端复杂度，且不能从根本上解决问题
• 单纯增加渠道数量：成本较高，且某些场景（如 Coding Plan）可能需要特定模型

Feature Category / 功能分类

Load Balancing / Failover / 负载均衡 / 故障切换

Additional Context / 其他补充信息

此功能与 #858（Support rate limits）是互补关系：

• [Feature/功能]: Support rate limits #858：被动响应已发生的 Rate Limit（根据 Retry-After 等待）
• 本 Issue：主动预防 Rate Limit（限制并发、请求排队）

两者结合可以实现更完善的流量控制策略。