Code Review：fix(fsBridge): handle EBUSY in readFile/readFileBuffer (#1754)

变更概述

本 PR 修复了 Windows 文件系统中 EBUSY（资源忙/被锁定）错误未被处理的问题。在 fsBridge.ts 的 readFile 和 readFileBuffer provider 中，将 EBUSY 与已有的 ENOENT 并列处理，返回 null 而非抛出异常，同时新增单元测试验证三种场景。另包含 @office-ai/aioncli-core 版本从 0.30.1 升级至 0.30.2（关联的上游修复）。

方案评估

结论：✅ 方案合理

将 EBUSY 与 ENOENT 统一处理（均返回 null）的语义是合理的：二者都代表当前无法读取该文件，而不是系统级错误。变量提取（const code = ...）消除了重复类型转换，代码更简洁。方案与现有架构完全一致，无过度工程化。

问题清单

🔵 LOW — 测试文件：未使用的 Mock 类型导入

文件：tests/unit/process/bridge/fsBridge.readFile.test.ts，第 2 行

问题代码：

import type { Mock } from 'vitest';

问题说明：Mock 类型从未被使用，oxlint 已报出 no-unused-vars 警告。

修复建议：删除此行。

🔵 LOW — 测试文件：辅助函数作用域可提升

文件：tests/unit/process/bridge/fsBridge.readFile.test.ts，第 117、122 行

问题代码：

async function setupProviders() { ... }
function makeErrnoError(...) { ... }

问题说明：两个函数均未捕获 describe 闭包内的任何变量，但定义在 describe 块内，oxlint 报出 consistent-function-scoping 警告。

修复建议：将两个函数移至 describe 块外部（文件作用域）。

汇总

结论

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

核心修复逻辑正确，测试覆盖 EBUSY/ENOENT/其他错误/成功读取四种场景，所有 CI 检查通过。仅两处 LOW 级别的 lint 警告在测试文件中，不影响正确性。

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

PR Fix 验证报告

原始 PR: #1754
修复方式: 直接推送到 fix/sentry-ELECTRON-D1

总结： ✅ 已修复 2 个 | ❌ 未能修复 0 个