feat(kilo): 接入 Kilo Gateway 免费层作为第四渠道

Kilo Gateway（api.kilo.ai/api/gateway）对外是标准 OpenAI 兼容协议
（/chat/completions + /models），无需登录、无门禁伪装（与 Zen 的关键差异：
Zen 要伪造 UA/session/tools 并过滤伪工具调用，Kilo 不需要）。

- 免费模型由上游 /models 的权威 isFree 布尔直接过滤（实测 395 个模型中
  17 个为 true，含 kilo-auto/free、stealth/space-bunny-alpha、openrouter/free
  等无 :free 后缀者），**不做探活**：探活会白耗本就极小的免费配额且结果
  随上游免费池波动不稳定；上游增删自动跟随，无静态白名单。
- 免费模型显式标 x0 倍率；name/context_length/max_completion_tokens/
  supported_parameters/input_modalities 透传为中立 Model 元数据。
- 思考字段是 delta.reasoning（不是 Zen 的 reasoning_content）。
- 匿名请求头**不带 Authorization**：Kilo 把任何 Authorization 头当真实凭证
  校验，带 Bearer public 占位符反而回 401 INVALID_TOKEN（与 Zen 相反）。
- 虚拟凭证行（同 Zen）：probe_quota 恒 probe_failed=True → health NULL
  「未知」而非耗尽；删除后重启复活，也可在凭证页「添加 Kilo Gateway」补回。
- 错误分类同 Zen：401/400/404/422→INVALID、429→SOFT、403→REQUEST；
  限流交引擎软冷却换模型，本包不自建熔断。
- 独立 pacer（KILO_CHAT_MIN_INTERVAL，热更项，默认 0），与 zen/CB/TRAE
  互不排队；stream_chat 在 finally 归还并发名额。
- 新增 KILO_API_ENDPOINT / KILO_ALLOWED_ENDPOINTS（端点白名单，仅防误配）。
- 前端补 Provider 联合类型、渠道元数据（KL / --chart-2）、KiloCode Mono
  图标、凭证页一键补回与签到隐藏、API Key 绑定与 Playground 强制渠道选项、
  quotaSemantics 免费层文案。
- 文档同步 README / PROPOSAL(Q46) / TECHNICAL(§3.15) / docker-compose env。

Author: RobbsLuo

PROPOSAL.md

@@ -1,6 +1,6 @@
 # Coding2API 立项决策
 
-把 CodeBuddy、TRAE SOLO 与 OpenCode Zen 三个上游通道，统一封装为 OpenAI 兼容 API，并提供公共凭证池、统一调度与按人用量统计。
+把 CodeBuddy、TRAE SOLO、OpenCode Zen 与 Kilo Gateway 四个上游通道，统一封装为 OpenAI 兼容 API，并提供公共凭证池、统一调度与按人用量统计。
 
 > 本文档记录立项决策与可行性核实。实现细节见 [TECHNICAL.md](TECHNICAL.md)，使用与部署见 [README.md](README.md)。
 
@@ -51,12 +51,13 @@
 | Q43 | macOS 部署模板去本地路径（占位符 + 安装脚本渲染） | `deploy/launchd/com.coding2api.plist` 与 `deploy/newsyslog/coding2api.conf` 原把开发机家目录绝对路径与用户名（`<user>:staff` 属主）写死在仓库里——克隆到别处不可用，还泄露本机目录结构。launchd 与 newsyslog **都不展开 `$HOME` / 环境变量**，路径必须写死，无法像 systemd 模板那样用约定路径，所以改成模板占位符 `__PROJECT_ROOT__`（路径）+ `__LOG_OWNER__`（属主），由 `scripts/install-launchd.sh`（新增，渲染 plist → `~/Library/LaunchAgents` → bootout/bootstrap，bootout 异步需重试）与 `scripts/install-newsyslog.sh`（改为渲染后写入 `/etc/newsyslog.d/`）在安装时替换成本机实际值。`test_deployment_assets.py` 锁三条不变量：全仓库无个人家目录路径、模板含占位符、安装脚本渲染占位符；newsyslog 与 launchd 模板的路径一致性改为**模板对模板**比对（渲染后仍校验本机已装 plist）。systemd / logrotate 的 `/opt/coding2api`、`/var/log/coding2api` 是约定部署路径非个人路径，保留不动。无 schema / 配置变更 |
 | Q44 | Zen 独立聊天节流（不再与 CB/TRAE 共享 pacer） | 原先 zen 的 `ZenProvider(pacer=chat_pacer)` 与 CodeBuddy/TRAE 共用同一个全局 pacer（`codebuddy_chat_min_interval`，默认 5s，min=max=5 → 固定 5s）。该 pacer 的存在理由是避开 CB 11128 / TRAE 流内错误的**账号级频率风控**，而 zen 是匿名免费层、无账号、无此类约束。共享的后果是**自伤式延迟**：任何 CB/TRAE 请求刚发出，紧随的 zen 请求就要在 pacer 里空等满 5s 才打上游；单一用户连发或 IDE 并发多个 zen 请求时，第 2、3 个请求 TTFB 实测 +5s、+10s（并发 3 个 zen：9.2s / 13.5s / 18.1s，去掉节流后应基本齐平）。实测确认**不是网络问题**：首 token 直连与走本机代理（127.0.0.1:7897）互有胜负、无稳定收益（`GET /models` 直连 0.29s vs 代理 0.60s；chat TTFB 直连 ≈ 代理），故不引入代理。改为 zen 用独立 `Pacer`，新增热更项 `ZEN_CHAT_MIN_INTERVAL`（默认 **0** = 不节流）；仍保留可调旋钮，若上游日后对匿名层限流可调大。CB/TRAE 继续共享原 pacer，互不影响。无 schema 变更 |
 | Q45 | 聊天节流按凭证分桶并允许桶内并发（同渠道同模型并发不再串行台阶） | Q44 给 zen 拆了独立 pacer 后，CB/TRAE 的 `chat_pacer` 仍是**一把全局 `asyncio.Lock` + 单个 `_last_started`**：任何两个请求（哪怕不同账号、不同模型）都串行排队，后到者按 `interval - elapsed` 补足等待。实测 3 个并发 CB 请求 TTFB ≈ 1.55 / 6.71 / 11.47s（正好 +5s、+10s 台阶）；把间隔热更为 0 后 6 并发 TTFB ≈ 1.48–1.84s、总 1.84s → 延迟完全来自节流排队而非上游。**关键**：并发请求常被会话粘性/健康度排序收敛到**同一个凭证**（DB 里 6 条并发全部命中 `cred_75e8edcf`），所以只按凭证分桶、桶内继续排队并不能解决，必须同时允许桶内并发。改为 `Pacer(min, max, *, allow_concurrent=False)`：`allow_concurrent=True`（仅聊天 pacer）时按桶（渠道前缀 + 凭证身份摘要）维护**在途计数**——同桶已有在途请求则新请求**立即放行**，只有桶空闲、且距上次请求开始不足最小间隔时才补足等待（即只有「上一请求已结束、紧接着又来一个」的顺序连发才节流）。请求结束由 provider `stream_chat` 的 `finally` 调 `pacer.release(key)` 归还名额（async generator 被提前关闭时依赖 asyncio 的 asyncgen finalize，延迟归还只会让节流略松、不会误排队）。`allow_concurrent=False`（后台任务 pacer）保持原严格串行语义不变。桶键用 `stable_key(provider, identity)`：CB 取 `account_uid or user_id or bearer_token`、TRAE 取 `uid or access_token`、zen 用渠道常量；`identity` 缺失回落该渠道单桶。CB/TRAE 仍共享同一 pacer 实例，但桶键带渠道前缀 + 身份摘要，彼此不互堵；`CODEBUDDY_CHAT_MIN_INTERVAL` 语义从「跨渠道全局间隔」变为「同渠道同凭证的顺序连发间隔」（默认 5s 不变）。无 schema 变更 |
+| Q46 | Kilo Gateway 免费层（第四渠道 `kilo`） | 把 [Kilo Gateway](https://kilo.ai)（`api.kilo.ai/api/gateway`）免费层接成第四个 provider（`KNOWN_PROVIDERS` 加 `"kilo"`，**无 schema 变更**）。**协议是标准 OpenAI 兼容**（`/chat/completions` + `/models`），既无私有信封也无门禁伪装——与 Zen 的关键差异正在此：Zen 要伪造 UA/session/tools 并过滤伪工具调用，Kilo 完全不需要。**免费模型有权威标记**：`/models` 每个条目带 `isFree` 布尔（实测 2026-09-29 共 395 个模型、17 个 `isFree=true`，含 `kilo-auto/free`、`stealth/space-bunny-alpha`、`openrouter/free` 等无 `:free` 后缀者），据此**直接过滤**免费集——**不做探活**（与 Zen 相反）：探活会真发一次推理、白耗本就极小的免费配额（网关级约 200 req/h/IP），且结果随上游免费池波动不稳定，`isFree` 已足够权威。免费模型显式标 **x0 倍率**（`credit_rate=0.0`）；`name`/`context_length`/`top_provider.max_completion_tokens`/`supported_parameters`（含 `tools`）/`architecture.input_modalities`（含 `image`）透传为中立 `Model` 元数据。思考字段是 **`delta.reasoning`**（**不是** Zen 的 `reasoning_content`）。**凭证模型用虚拟凭证行**（同 Zen）：Kilo 无凭证/无额度接口，池里种一条空凭证复用现有调度/冷却/统计（`probe_quota` 恒 `probe_failed=True` → health NULL「未知」，**不是耗尽**）；删除后重启复活，也可在凭证页「登录渠道账号」点「添加 Kilo Gateway」立即补回，永久停用请用「暂停」。**错误分类**（同 Zen 口径）：401→`INVALID`（无凭证，401 只表示该模型需要付费 key/BYOK，避免强制付费模型硬禁用整条渠道）、429→`SOFT`（软冷却换模型）、400/404/422→`INVALID`、403→`REQUEST`。限流交引擎软冷却处理，**本包不自建熔断**——上游 429 报错自报限额来自 OpenRouter 共享池（`limit_source: openrouter_shared_capacity`），证实免费池实为 OpenRouter 转发。新增 `KILO_API_ENDPOINT` / `KILO_ALLOWED_ENDPOINTS`（端点白名单，Kilo 不带真实 Token）/ `KILO_CHAT_MIN_INTERVAL`（热更项，独立 pacer、默认 0 = 不节流，与 zen / CB / TRAE 互不排队） |
 
 ## 2. 目标与非目标
 
 ### 目标
 
-- 单一 OpenAI 兼容端点，后面挂 CodeBuddy、TRAE 与 OpenCode Zen 三个上游
+- 单一 OpenAI 兼容端点，后面挂 CodeBuddy、TRAE、OpenCode Zen 与 Kilo Gateway 四个上游
 - 凭证由 admin 集中维护，全员共享，调度器自动挑健康的号
 - 按人统计用量（请求数、成功率、token、耗时与首字延迟）
 - 上游死亡自动冷却，不反复踩死号
@@ -65,7 +66,7 @@
 ### 非目标（明确不做）
 
 - **不做配额/限流**：上游是订阅制通道，成本不随 token 线性增长；10 人规模靠统计页可见性约束滥用
-- **不做通用 provider 网关**：只支持 CodeBuddy / TRAE / OpenCode Zen 这几个明确接入的上游，硬编码，不做插件系统
+- **不做通用 provider 网关**：只支持 CodeBuddy / TRAE / OpenCode Zen / Kilo Gateway 这几个明确接入的上游，硬编码，不做插件系统
 - **v1 不做 Anthropic 协议**
 - **不做旧项目数据迁移**
 - **不做自更新脚本**