[cli] getMaxFileSize: chunk stat calls or short-circuit on huge files

[luojiyin1987]

TODO(perf, #78) in src/utils/batch-lint.ts (getMaxFileSize) currently
stats every file with one Promise.all. For very large repositories
(数万 .md 文件) this produces a filesystem stat burst that hasn't been
measured yet.

背景

• 父 issue：#77（性能优化路线图）
• P1 实现：#78 / PR #79
• 代码位置：src/utils/batch-lint.ts 的 getMaxFileSize
• 当前实现：Promise.all(filePaths.map(p => stat(p))) → reduce(max size)

为什么不是 blocker

• --threads auto 是 opt-in（用户显式选择）
• stat 失败会通过 Promise.all 一次性向上抛，与现有 lintWorker 读文件失败的处理边界一致
• P1 验收标准的 RSS / wall time benchmark 已经覆盖到 8 MiB 总输入的真实场景，未见异常

目标

在 --threads auto 模式下，给 getMaxFileSize 的 filesystem 行为加一个上界，不改变阈值表和外部语义。

可选方向（任选其一或组合）：

1. 分批 stat：将 Promise.all 改成 chunked / bounded concurrency（例如 64 / 128），避免瞬间打开 N 个 fd
2. 短路：当找到一个 >= ADAPTIVE_HUGE_FILE_THRESHOLD（5 MiB）的文件就提前返回 —— 因为再大的文件不再影响阈值表
3. 两者结合：先短路（5 MiB 命中即返回），否则分批 stat

非目标

• 不改变 --threads auto 外部语义
• 不修改 resolveAdaptiveConcurrency 的阈值表
• 不修改数值型 --threads N 路径
• 不动 worker 池大小

验收标准

• 选择 1 / 2 / 3 中的方案并在 PR description 里说明取舍
• 至少 1 个新单测覆盖所选行为
  • 分批：可加一个 mock 让 stat 触发 N 次 + 验证分批生效
  • 短路：构造一个目录中有一个 5 MiB 文件 + 多个 1 MiB 文件，验证只 stat 了部分文件就返回
• npm test / npm run lint / CI 全部绿
• 默认行为完全不变（包括数值 --threads、未传 --threads、--threads auto 在小仓库下）
• 如有新增 benchmark，附在 PR description

关联

• 父 issue：[performance] 性能优化路线图：在文件读取移入 worker 后继续降低内存压力  #77
• P1 子 issue：[cli] 为大 Markdown 文件增加自适应并发控制 #78
• 触发 PR：feat(cli): add --threads auto to cap worker concurrency for large files (#77 P1) #79
• TODO 引用：src/utils/batch-lint.ts 顶部的 TODO(perf, #78) 注释（合入 feat(cli): add --threads auto to cap worker concurrency for large files (#77 P1) #79 后保留，指向本 issue）

不阻塞

本 issue 不阻塞 #79 合并。TODO(perf, #78) 注释已经留好指针。