模型请求失败时错误横幅只显示状态码，上游返回的 errorType 与响应体被丢弃

**提交人**: nian qian
**客户端版本**: 0.1.38

---

## 现象

一个已有的长对话切换到中转供应商后无法继续，错误横幅只显示：

```
API Error: 400 content-blocked (request id: 20260810131645440520729st7dd1iHwN5ZK)
```

顶部另有一条「供应商「ag-Claude」请求失败：未知错误，请查看日志了解详情」。界面上没有任何可用于定位的信息。

但翻 `logs/agent-2026-08-10.ndjson` 会发现代理层其实已经拿到了关键字段，只是没有展示：

```
reqId : 714
status : 400
contentType : application/json; charset=utf-8
bytes : 158
errorType : agent_router_api_error
```

`errorType: agent_router_api_error` 是判断这次失败性质的决定性信息——它说明拒绝动作发生在中转层自身的路由逻辑，请求根本没到达 Anthropic（官方 400 的 `error.type` 只有 `invalid_request_error`，且不存在 `content-blocked` 这个错误码）。这条信息只出现在日志里，横幅完全没有体现。

同时代理层记录了响应体大小为 158 字节，但正文内容既未展示也未落盘，无从得知中转层给出的具体拒绝理由。

## 复现步骤

1. 用某个供应商跑一个较长的对话（本例约 17 分钟，上下文已相当大）
2. 中途将该对话切换到另一个中转供应商
3. 继续对话

结果：该对话必现 400，重试无效；**同一供应商新建对话则完全正常**。

耗时随重试快速衰减，说明后续请求是被直接拒绝而非真正执行：

```
13:15:19 durationMs : 11725
13:15:27 durationMs : 7185
13:16:45 durationMs : 2813
```

对应的三个 request id：

```
202608101315196935666016dvlmJSwuvxY6
2026081013152748587029qzm4guFb4ZjLs
20260810131645440520729st7dd1iHwN5ZK
```

这里要强调：因为该供应商在新对话里工作正常，问题并不是供应商不可用。但恰恰由于错误信息被丢弃，用户无法判断真实原因是中转层的内容审查、请求体过大、还是 Cindy 在跨供应商延续会话时构造的请求本身有问题——这三种情况的处理方式完全不同。

同一时段该供应商还返回过另外两种错误，横幅同样只有一行文本，没有更多上下文：

- `403 insufficient balance`
- `424 No available accounts: no available accounts`

## 期望行为

1. 错误横幅展示上游返回的 `errorType` 和响应体原文，而不是只留一个 request id
2. 横幅提供「查看详情」入口，可查看该次请求的完整上游响应、耗时以及对应的日志位置
3. 对明显不属于 Anthropic 官方错误码的响应（如 `content-blocked`、`agent_router_api_error`），提示用户该错误来自中转层而非模型服务本身，避免被误判为账号或额度问题

## 实际行为

横幅只显示 `API Error: 400 content-blocked (request id: ...)` 与「未知错误，请查看日志了解详情」。用户必须自行定位到 `%APPDATA%/CindyGlobal/logs/agent-*.ndjson`，按 request id 检索，才能看到 `errorType`；而 158 字节的响应体正文即使翻日志也拿不到。

由于缺少这些信息，实际排查中一度误判为账号可用性或额度问题，耗费了大量时间在错误方向上。
---
**OS**: win32 x64 (10.0.26200)
**界面语言**: zh-CN

Start by reproducing the failed cross-provider conversation and trace the request by its request ID in %APPDATA%/CindyGlobal/logs/agent-*.ndjson. Identify where the upstream errorType and 158-byte response are lost between the agent response and the error banner; done means the banner and its details view expose the upstream response, timing, and log location, with clear indication when the error comes from the intermediary.

Written by the indexing model from the issue text.