正常对话时报 403 错误：Error invoking remote method 'codesign:v1:generate'

正在修复此问题。测试连接和实际调用的请求方式可能存在差异（如 model 参数、请求头、endpoint 不同），导致 403 策略拦截。

感谢反馈，复现描述很清楚。

从当前代码看，这个现象是可能出现的：**“测试连接”与“正常对话生成”走的是不同请求路径**。
- 设置页“测试连接”只探测 provider 的 `/models` 可达性与鉴权。
- 聊天对话会走 `codesign:v1:generate`，再进入真实的生成请求（模型推理调用）。

所以会出现“测试连接通过，但生成时报 403（Your request was blocked）”的情况：`/models` 可用不代表生成端点一定放行。

另外，当前诊断里会把 `403` 和 `401` 归到同一类（密钥/权限问题），因此提示可能偏泛化。

**Relevant code:**
- `apps/desktop/src/renderer/src/components/Settings.tsx:286` — 设置页“测试连接”调用 `connection.testProvider(...)`
- `apps/desktop/src/main/connection-ipc.ts:410` — `runProviderTest` 仅对 `/models` 做 GET 探测
- `apps/desktop/src/main/connection-ipc.ts:426` — 非 2xx 时按 HTTP 状态返回连接测试错误
- `apps/desktop/src/main/index.ts:448` — 对话生成走 `codesign:v1:generate`
- `apps/desktop/src/main/index.ts:581` — 生成调用 `runGenerate(...)`（真实模型请求）
- `apps/desktop/src/main/connection-ipc.ts:205` — `403` 被归类为 `401` 类别
- `packages/shared/src/diagnostics.ts:61` — 诊断里 `401/403` 同归 `keyInvalid`
- `README.md:119` — 当前发布仍是 `v0.1.x` 早期阶段

**Need more info:**
- 你当前“激活中的 provider / model / baseUrl”分别是什么？
- 是否使用了中转网关或自定义 `baseUrl...

补一条同类现场证据，和本 issue 高度一致：

- 现象：生成阶段报错，弹窗内容为

```text
Error invoking remote method 'codesign:v1:generate': CodesignError: 403 Your request was blocked.
```

- 用户补充：`无论是 codex 还是 claude 都不行，是 cpa 反代的`
- 截图显示：UI 仍然只是通用的“生成失败 / 生成过程中出错了”，没有给出更可操作的代理/上游拦截解释

这条证据进一步支持当前判断：
- 测试连接可通过，不代表真实生成请求会通过
- 在反代 / 中转 / 自定义 provider 场景下，生成请求路径更容易被上游策略拦截
- 问题并不局限于单一模型，至少用户反馈里 `codex` 和 `claude` 两条链路都可能触发同类 403 blocked

建议把这类 case 一并纳入该问题，而不是按单个模型拆散处理。若后续需要，可再补 diagnostics zip / main.log 佐证。

Another potentially related signal: see #136.

In at least one user screenshot, the top bar shows the active model as `opus-4-7`, while the currently active provider card in Settings shows `claude-3-5-haiku-20241022` and is still marked `当前`.

That suggests the UI may be exposing two different model states at once (top-bar active vs provider-card default/resolved state). If true, this could make 403 debugging much harder because the user may think the generate request is using one model while the app internally resolves another.

@Sun-sunshine06 同步一下进度 —— 你 4/22 02:51 提到正在修复，请问目前进度如何？

我这边正在并行做一个更通用的修复 PR（暂编号 #130 范围），把生成失败路径接到现有的 `diagnose()` hypothesis 系统，覆盖范围包括：

- 404 + custom baseUrl 不含 /v1 → `missingV1` hint + auto-fix
- 403 + body 含 `Your request was blocked` / `blocked` / Cloudflare ray id → 新增 `gatewayWafBlocked` hint（专门给本 issue 这种 WAF 拦截场景，避免被误归到 `keyInvalid` 让用户白查 API key）
- 401/403 不含 WAF 文案 → 维持 `keyInvalid`
- 500 + `not implemented` → 网关不支持 Messages API hint（与 #158 联动）
- 400 + `instructions are required` → 提示切换 wire 到 openai-chat（与 #134 联动）

如果你那边的修复方向不同/已经动手，麻烦贴一下 PR 链接或当前思路，避免重复工作。如果还没起手，我这个 PR 落地后会顺带 close 本 issue，你来 review 即可。

cc @hqhq1025