perf(batch-lint): bound getMaxFileSize stat concurrency to 128

[luojiyin1987]

Summary

• getMaxFileSize no longer issues an unbounded Promise.all over every file. It now reuses runTasksWithLimit with a new STAT_CONCURRENCY_LIMIT = 128 constant, so very large repositories no longer hit an N-fd filesystem stat burst.
• Real max-size semantics, empty-list → 0, and reject-on-stat-failure behavior are all preserved (only the in-flight stat count is bounded).
• Updated the misleading TODO(perf, #78) comment to reference [cli] getMaxFileSize: chunk stat calls or short-circuit on huge files #80, and added inline comments explaining the design tradeoff.

Why throttling instead of short-circuiting

We chose bounded concurrency (#1) over the short-circuit variant (#2). getMaxFileSize() must keep returning the true maximum file size: src/lint-md.ts (line #131) logs max file ${maxMiB} MiB in --threads auto --dev mode, and an early return on a 5 MiB hit would make both the returned max and the log inaccurate when a larger file follows. Throttling caps only the filesystem burst and leaves external behavior identical. STAT_CONCURRENCY_LIMIT = 128 is an empirical pick (the issue itself suggests 64/128 as examples), not a benchmark-derived value — the goal is an upper bound, not a tuned constant.

Scope / non-goals

• Only affects --threads auto (the only path that calls getMaxFileSize).
• Does NOT touch resolveAdaptiveConcurrency's threshold table, the cpuLimit computation, runTasksWithLimit itself, the numeric --threads N path, or the worker pool size.

Test plan

• Added a unit test that mocks fs/promises.stat with a delay and asserts concurrent stat calls stay <= STAT_CONCURRENCY_LIMIT while still returning the true max.
• npm test (75 passed) and npm run lint are green.

Closes #80

🤖 Generated with opencode