feat: improve sub2api recent error analysis

docs/MDTODO/details/sub2api-upstream-reliability/R2.2.6_Task_Report.md

@@ -0,0 +1,68 @@
+# R2.2.6 任务报告
+
+## 结果
+
+- 完成纯分析 CLI 增强，未修改 Sub2API 配置、账号 runtime、YAML 或运行面。
+- `runtime errors --all-groups` 默认使用 Kubernetes 风格概要表，支持所有分组概览和 `--group <name-or-id>` 精确下钻。
+- 指定分组详情新增原生 `openai-token-stats` 模型时延表，以及原生 `request-errors` 的模型、账号、状态、同步/流式、阶段、入口和精确路径分布。
+- 客户错误画像由 CLI 自动读取原生分页并完成统计，只对 request ID 样本做有界渐进披露，不要求用户手工调整 limit。
+- `trace` 继续以原生 requests 和 system-logs 为主；requests 缺记录时只在同一 `--since` 窗口查询原生 request-errors，runtime 日志仅补原生索引缺失的事件。
+
+## 最近 60 分钟全分组证据
+
+- 三个分组合计约 468 个请求、11 个客户可见错误，客户错误率约 2.35%，上游错误率约 4.70%。
+- `unidesk-codex-pool`：约 61 至 67 个请求、7 个客户错误，窗口滚动错误率约 10.45% 至 11.48%。
+- `自用`：407 个请求、4 个客户错误，错误率 0.98%。
+- `grok`：窗口内无流量、无错误。
+- 查询时并发约 8/218、队列为 0；当前快照不能代表错误瞬间，但没有证据支持把全局并发不足作为近期主因。
+
+## 分组根因
+
+- `unidesk-codex-pool` 的 7 个客户错误全部是：
+  - 模型 `gpt-5.6-luna`；
+  - 账号 27；
+  - 同步 `/v1/responses`；
+  - 上游阶段；
+  - 5 个 502、2 个 503。
+- `自用` 的 4 个客户错误全部是：
+  - 模型 `gpt-5.6-sol`；
+  - 流式 `/responses`；
+  - 账号 15 占 3 个 504，账号 27 占 1 个 502。
+- 近期失败不是所有模型、账号和路径均匀恶化，而是两个窄错误簇。
+
+## request trace 证据
+
+- `c76b05df-ad84-4055-bb5a-d363a77e94a1`：约 197.056 秒后账号 27 返回 503，首次 failover、下一次选号失败和最终 502 发生在同一毫秒，选号错误为 `context canceled`。
+- `2c1211b5-1f9f-441a-9ef8-1f80795097cd`：约 50.863 秒后账号 27 返回 502，failover 与 `context canceled` 同时发生。
+- `d66d7ea7-4e78-475c-8f93-b315435b79f7`：约 1772.971 秒后账号 15 返回上游 504，随后立即 `context canceled` 并包装成最终 502。
+- `4ee54daa-f41c-4f50-bd72-11080c38e299`：约 730.835 秒后账号 27 返回 502，约 1 毫秒后 `context canceled`。
+- 四个近期代表请求都已进入 failover；临时不可调度规则也有真实命中。直接传播点是 failover 开始时原请求上下文已经取消，不是缺少规则或没有触发切号。
+
+## v0.1.153 官方源码判断
+
+- OpenAI Responses handler 的转发和下一次账号选择都复用 `c.Request.Context()`。
+- 收到 `UpstreamFailoverError` 后 handler 记录失败账号并直接继续选号；若客户请求上下文已经取消，下一次选择会立即返回 `context canceled`。
+- `gateway.openai_response_header_timeout` 是 v0.1.153 已有配置，作用范围是等待 OpenAI 上游 HTTP 响应头，不影响响应头之后的流式传输。
+- v0.1.153 发布说明没有修复上述 failover 上下文生命周期问题，因此没有证据支持回退版本。
+
+## 候选方案
+
+1. 配置级有界缓解，不涉及 Sub2API 源码变更：
+   - 设置 OpenAI 专用 response-header timeout，可让真正卡在响应头前的 730 秒或 1773 秒请求更早转成 failover，从而保留切号窗口。
+   - 它不能解决 50 至 197 秒内已经返回的 502/503，也不能解决流式内容已经提交后的失败。
+   - 近期 TTFT P99 在分组 2 约 231 至 245 秒、分组 3 约 101 秒；TTFT 不是响应头时延，因此 255/270 秒只能作为排除过低值的观测下限，不能直接视为安全配置。
+2. 精确源码方案，涉及 Sub2API 源码变更：
+   - 增加响应头实际等待时长与首个语义流事件时长，区分响应头前等待和响应头后无事件。
+   - 在下游尚未提交且客户 deadline 仍有预算时，为单次上游尝试使用更短的 attempt context；超时后在原客户 context 内切号。
+   - 明确禁止在客户已经断开后继续后台重试，避免无效上游消耗。
+3. 窄路由治理：
+   - 分组 2 优先治理账号 27 的 `gpt-5.6-luna` 能力和错误分类；分组 3 优先治理账号 15/27 的 `gpt-5.6-sol` 长流式等待。
+   - 不建议用降低全池并发、账号 pinning、扩大临时不可调度时长或版本回退替代根因治理。
+
+## 验证
+
+- `bun --check` 通过：`runtime.ts`、`remote-python-sync.ts`、`output.ts`。
+- `bun test scripts/src/output.test.ts`：2 通过、0 失败。
+- `git diff --check` 通过。
+- 原入口读取验证通过：全分组概要、分组 2/3 详情、四个近期 request trace。
+- 超过 3000 行的既有 `remote-python-sync.ts` 拆分已登记为 R2.2.7，本任务未混入大范围机械重构。

docs/MDTODO/sub2api-upstream-reliability.md

@@ -35,6 +35,12 @@
 #### R2.2.5 [completed]
 
 增强 Sub2API CLI 的纯分析能力：只读披露实际 OpenAI response-header timeout、TTFT 分位数、长等待请求和 failover 剩余时间窗，并使用原生 admin/ops 数据分析候选配置，不修改 Sub2API 配置、源码或运行面，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.5_Task_Report.md)。
+#### R2.2.6 [completed]
+
+继续纯分析 Sub2API timeout 与 failover：按所有分组、模型、账号和请求类型定位超长 TTFT 与客户错误，区分响应头前等待、流式提交后失败和无候选，评估观测下限是否可能缓解且不做配置实验或运行面变更，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.6_Task_Report.md)。
+#### R2.2.7
+
+按仓库 P0 拆分超过 3000 行的 `remote-python-sync.ts`：把大段内嵌 Python 按 trace、sync/validate 与 sentinel 职责迁入原生模块，单文件收敛到 2000 行以下，并保持受控 CLI 行为与只读诊断契约不变，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.2.7_Task_Report.md)。
 ### R2.3
 
 调查并收敛 Sub2API 原生 system-log 索引未保留策略事件的能力缺口，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R2.3_Task_Report.md)。