feat(channels): 渠道列表同时展示 TTFT 与总耗时

[faithleysath]

提交前必读（请勿删除本节）

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 开启透传后的转发相关反馈不接受 issue；透传模式会直接转发请求，请自行确认上游行为。
• 不接受 Coding Plan、逆向渠道、第三方封装接口，以及将 Codex 接口反代为通用 API 后产生的兼容性问题；Codex API 自身特有的协议或行为也不应被当作标准 OpenAI API 行为，相关问题请先向渠道或接口提供方确认。
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

您当前的 newapi 版本

v1.0.0-rc.23-nexus.2

提交确认

• 非重复 issue: 我已搜索现有 Issues，确认目前没有类似 issue。
• 提交前必读: 我已完整阅读上方“提交前必读”，并已查看文档、项目 README 且向 AI 提问，确认这不是使用、配置或接入类问题，且现有版本无法满足需求。
• 模板完整: 我未删除此模板中的任何引导内容或小节标题，并已按要求完整填写。
• 维护成本: 我理解项目维护者精力有限，不遵循模板要求的 issue 可能会被无视或直接关闭。

功能描述

当前渠道页面的“响应”列只展示一个 response_time。该值实际表示渠道测试从发起到完整结束的总耗时，无法区分上游的首 Token 响应速度和后续生成耗时；同一个总耗时可能来自 TTFT 很高，也可能来自首 Token 很快但生成内容较长。

建议每次渠道测试记录并展示两个值：

• TTFT：从测试请求发起到收到第一个有效输出内容事件的耗时。SSE keep-alive、仅角色增量、usage-only chunk 等不应视为有效首 Token。
• 总耗时：从测试请求发起到完整响应读取、解析和校验结束的耗时，保持当前 response_time 的统计口径。

页面可在现有“响应”单元格内分两行紧凑展示，例如 TTFT 820 ms、总耗时 3.4 s；移动端渠道卡片同步展示。TTFT 与现有“TTFT 超时率”是不同指标，不应互相替代。

接口建议保持向后兼容：继续以 response_time 表示总耗时，新增独立的毫秒字段（例如 ttft），不要把 response_time 改为对象或改变其原有语义。手动单渠道测试和定时/批量渠道测试应更新同一组数据。非流式测试或未取得可靠首 Token 时间时，TTFT 显示 -，总耗时仍正常显示。

本需求只扩展现有渠道列表的最近一次测试结果，不依赖 #39 的渠道历史监控与百分位指标。

验收条件：

• 成功的流式渠道测试会同时持久化最近一次 TTFT 和总耗时，单位与字段语义明确。
• 渠道表格和移动端渠道卡片均同时展示 TTFT 与总耗时，长数值不会挤压或遮挡其他内容。
• response_time 继续表示总耗时，已有接口消费者和按响应时间排序行为不被破坏。
• 非流式测试、无有效首 Token 或旧数据没有 TTFT 时显示 -，不伪造为 0 ms。
• keep-alive、空增量、仅角色增量和 usage-only chunk 不会提前结束 TTFT 计时。
• 手动测试与定时/批量测试采用一致的计时和更新逻辑。
• 新增前端文案补齐现有全部 locale，并覆盖后端计时语义及前端无数据展示的回归测试。

应用场景

管理员在渠道页面比较和排查上游质量时，需要快速判断“慢”发生在哪个阶段：TTFT 高通常意味着排队、网络或上游首响应慢；TTFT 低但总耗时高则可能只是模型生成较慢或测试输出较长。仅显示总耗时会混淆这两类情况，容易误判渠道质量和优先级配置。