Code Review：fix(modelBridge): move OpenAI constructor inside try-catch (ELECTRON-6X) (#1797)

变更概述

本 PR 修复了 Sentry 问题 ELECTRON-6X（495 次事件，v1.9.1 回归）。改动涉及 src/process/bridge/modelBridge.ts 和对应测试文件：

1. 在初始化时对 api_key 执行 ?.trim()，使空白字符串在早期就变为空值，触发已有的 null guard；
2. 将 new OpenAI() 构造器调用移入 try-catch 块，防止 SDK v5 在凭证缺失时的同步 throw 逃逸为未处理 rejection；
3. 新增 3 个单元测试，覆盖空白 API key 和构造器抛错场景。

方案评估

结论：✅ 方案合理

双重防御策略（早期 trim + 构造器移入 try-catch）是正确且足够的。两个 OpenAI client 的构建路径（new-api 平台路径 + 默认路径）均已修复，与 IPC bridge 架构边界无关，改动最小化且有针对性。

问题清单

🔵 LOW — 第三个测试用例注释与实际执行路径不符

文件：tests/unit/bridge/modelBridge.test.ts，第 181 行

问题代码：

// Even if apiKey somehow passes the guard, the constructor error should be caught
const result = await fetchModelList({
  base_url: 'https://api.openai.com/v1',
  api_key: undefined as unknown as string,
  try_fix: false,
});

问题说明：传入 api_key: undefined 时，api_key?.trim() 返回 undefined，随即被第 366 行的 if (!actualApiKey) null guard 捕获并返回错误，构造器从未被调用。因此这个用例实际测试的是"null guard 正常工作"而非"构造器 throw 被 try-catch 捕获"，注释与实际执行路径不符。行为结果依然正确，只是语义略有偏差。

修复建议（可选）：更新注释以准确反映执行路径：

// api_key: undefined is caught by the null guard before reaching the constructor
// This test ensures the guard prevents unhandled rejections for undefined API keys

汇总

结论

✅ 批准合并 — 无阻塞性问题

修复方案正确，目标明确，测试覆盖充分。唯一的 LOW 问题仅为注释语义偏差，不影响合并。

本报告由本地 pr-review skill 生成，包含完整项目上下文，无截断限制。

CONCLUSION: APPROVED
IS_CRITICAL_PATH: false
PR_NUMBER: 1797

✅ 已自动 review，无阻塞性问题，正在触发自动合并。