refactor: move file reading into lint workers

[luojiyin1987]

摘要

将 batchLint 从「主线程预读取全部文件 → 静态分组 → 发送 contentList 给 worker」改为「主线程只发送单文件路径 → worker 自行读取并 lint」，消除主线程对全部文件内容的驻留，并删除有缺陷的 averaged-group.ts。

依赖：PR1（#69，已合并）建立的内存基准。

跟踪 issue：#73

变更

• src/types.ts — LintWorkerOptions.contentList 替换为 filePath；BatchLintItem 补 fixedResult 字段以保持现有 fix 模式行为不变。
• src/utils/lint-worker.ts — worker 接收 filePath，自行 readFile 后 lintMarkdown，返回 { path, lintResult, fixedResult }。
• src/utils/batch-lint.ts — 删除 fileContentList 预读取和 averagedGroup 分组；用 runTasksWithLimit 派发单文件任务；try/finally 中调用 lintWorkerPool.destroy()；worker 路径解析兼容测试/生产环境。
• src/utils/averaged-group.ts — 删除。
• __tests__/batch-lint.spec.ts — 新增 10 个 PR2 专项测试。

验收条件

条件	状态
worker payload 不包含 contentList	✓（仅 filePath）
最大在途任务数不超过 threads	✓（runTasksWithLimit(tasks, concurrency)）
worker 异常时 pool 仍会销毁	✓（try/finally）
lint/fix 输出与调整前一致	✓（worker 返回原 lintMarkdown 结果）
报告顺序按文件输入顺序	✓（runTasksWithLimit 保持顺序）
PR1 基准前后 RSS/耗时对比	✓（见下）

PR1 基线 vs PR2 复测

测试环境：Node.js 24.15.0，16 个文件、每个约 1,000,010 字节（总输入约 16 MB），刻意构造的超长英文段落，tsx 启动 CLI。每组 3 次取中位数。

线程	PR1 RSS 中位数	PR2 RSS 中位数	变化	PR1 wall time	PR2 wall time	变化
1	972,620 KiB	832,600 KiB	−140 MiB (~14%)	11.17s	10.52s	−0.65s
4	2,452,408 KiB	2,463,300 KiB	持平（噪声内）	4.38s	4.23s	−0.15s (~3%)

threads=1 时 RSS 下降来自主线程不再保留 fileContentList 和 averagedGroup 分组结构。threads=4 时 RSS 持平印证了 PR1 结论：剩余峰值由解析器 AST/临时对象贡献，PR5（基准驱动）再评估。wall time 改善来自去掉主线程 readFile 串行阶段和 averagedGroup 排序/分组过程。

报告顺序变化

旧实现按 averagedGroup 分配的线程组顺序返回结果（组内按文件输入顺序，组间按组序号）；新实现按文件输入顺序返回。已被 __tests__/batch-lint.spec.ts 中「报告顺序」测试断言。

测试

__tests__/batch-lint.spec.ts 现有 14 个测试（原 4 个 + PR2 新增 10 个），按验收条件分组：

验收项	测试
worker payload 不包含 contentList	路径 payload × 2
最大在途任务数不超过 threads	并发上限 × 2
worker 异常时 pool 仍会销毁	pool 销毁 × 2
lint/fix 输出与调整前一致	fix 行为 × 2
报告顺序按输入顺序	报告顺序 × 1

batch-lint.ts 行覆盖率从 42.42% 提升到 96.42%。

验证

npm run build                              # ✓
npx eslint --ext .ts,.tsx ./               # ✓
npm test -- --runInBand                    # 55/55 pass
npm run test:benchmark-memory              # ✓

下一步

PR3（可选输入字节上限）、PR4（fix 结果在 worker 内立即安全写入）在 PR2 合并后依次实施。

不实施：

• PR3：输入字节上限只能降低部分风险，不能保证避免 AST 膨胀 OOM；
• PR4：worker 内写入会混合解析与文件副作用，增加安全和错误恢复复杂度；
• PR5：增量报告会引入回调、背压和输出顺序决策，当前无基准证明必要。