perf: stat manifest files concurrently (#99) - #129

A note on the failing review check: it did not get as far as reviewing. The job log shows First-pass formatting failed: Trusted first-pass attribution invariant failed — the formatter counts generated with|by markers in the final comment and found more than its own footer. The likely trigger: the first-pass reply quoted or mentioned this PR body's own Generated with … footer mid-line, where sanitizeUntrustedBody's line-start anchor does not strip it.

Nothing in the diff is involved — Node Tests, UI Test and Release Package are green. Since the bot runs on opened only, a retry needs a workflow run arranged on your side; happy to reword the PR body if that helps the next pass.

🤖 Automated first-pass review

TL;DR

The change is small, well-scoped, and consistent with the file's existing concurrency helper; correctness looks sound. Only one real review point: the CHANGELOG classifies a performance change under ### Fixed, and the new test asserts overlap with a timing threshold that may be flaky on a loaded CI machine.

Analysis

• Correctness / semantics preserved: mapWithConcurrency maps results back in discovery order, and the post-loop for (const fingerprint of fingerprints) if (fingerprint) entries.set(...) preserves the previous insertion order and the per-file ENOENT tolerance (return null) while still rethrowing everything else. The hasStableIdentity logic is unchanged. No issue found.
• Concurrency limit 8 matches the earliest-timestamp probe mentioned in the description, so no new tuning constant is introduced.
• Test quality: maxInFlight > 1 is a good structural proof of overlap. The second assertion (< 20 * 50 ms wall clock) is a real-time threshold; on a heavily contended CI runner it can be marginal even though it would pass locally. Consider asserting a much looser bound (e.g. clearly less than the sequential sum with a wide margin) or deriving the bound from the observed overlap so the test proves behavior without a wall-clock race. Also confirm the fake stat wrapper does not hide the real ENOENT path — the existing "fails closed on permission errors but tolerates stat ENOENT" test still covers it, so this is only a note.
• CHANGELOG: the entry is placed under ### Fixed in [Unreleased]. It is a performance change, not a defect fix; ### Changed (or an explicit performance subsection) is more accurate under Keep a Changelog. This is a convention nit, not a blocker — the entry text itself is fine and correctly notes discovery order is preserved.
• No src/i18n.ts impact: this is host-side scanning, no user-facing strings were added or changed, so the eight-locale requirement does not apply.
• No architecture/module ownership change, so no ARCHITECTURE.md or Chinese-companion update is needed for this diff.
• PR title uses the perf: prefix while the branch/release intent is unclear; since release labeling is maintainer-applied, this is fine.

Suggested next step(s)

1. Move the CHANGELOG entry to ### Changed, or add a short performance note there, keeping the existing wording and the discovery-order guarantee.
2. Relax the wall-clock assertion in the new test (or replace it with an overlap-derived bound) so it cannot flake on a loaded CI host; keep maxInFlight > 1 as the primary structural assertion.
3. Confirm scanUsageManifest's callers do not rely on stats being observed in a strictly serialized order (e.g. logging or cancellation mid-loop); if they do, note it in the PR description.

🤖 Generated by DeepSeek as an automated first pass — not a maintainer decision.

Addressing the first-pass review:

1. CHANGELOG — moved the entry from ### Fixed to ### Changed, wording unchanged. (Earlier entries in this performance series went under Fixed as defect-repairs; happy to move them too if the maintainer prefers the stricter Keep-a-Changelog reading across the board.)
2. Timing assertion — maxInFlight > 1 stays the structural proof; the wall-clock bound is now half the sequential sum with a ~3× margin over a fanned-out run, so a loaded CI host cannot flake it.
3. Caller order assumptions — checked: scanUsageManifest's only outputs are the entries map (reassembled by index, so insertion order equals discovery order exactly as before) and the two timing fields. Nothing logs or cancels mid-loop; the only behavioral difference is which stats are in flight when a non-ENOENT error throws, and the observable outcome — the scan fails — is unchanged.

Addressing the review of 0c091c8, rebased onto current main:

1. Fatal stat no longer keeps scanning. mapWithConcurrency stops dequeuing after the first rejection. Calls already in flight may settle; nothing further starts. Test: a fatal stat stops scheduling files that have not started — 40 files, the first stat returns EACCES, at most the eight-worker ceiling starts, and a turn after the rejection starts nothing more.

2. No wall-clock bound. The overlap test holds every stat, waits until eight are in flight, releases one and asserts exactly one replacement under the same ceiling, then completes in reverse of start order and checks discovery order.

3. Changelog. The note is under Unreleased, not the published 2.5.0 section.