review: bound process concurrency in git capture and bootstrap scans

[kridaydave]

Split out of PR #39 (kridaydave:fix/good-first-issues) to address review concern #2.

The async refactor fanned every unit of work out with Promise.all at once. Measured live on a 400-file commit this peaked at 104 concurrent git child processes (the sequential version on main peaks at 1); a 60-file commit ran all 60 diffs simultaneously. The post-commit hook must stay invisible and fail-open, and on constrained CI or very large commits this risks FD/PID exhaustion.

Add mapWithConcurrencyLimit (order-preserving) in src/concurrency.ts and use it instead of the unbounded Promise.all fan-outs:

• runGitCapture: limit 8 per commit (also restores the documented "newest-file-last" captured ordering that the fan-out lost).
• bootstrap.ts findJsonlFiles / findWireJsonlFiles (recursive) and the three discoverSessions scans: limit 16.

The other three concerns (drop Antigravity #1, the captureDisabled cache fix #3, config-parse dedup #4) land in their own PRs, also split from #39.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Shreyan1]

The concurrency fix itself is genuinely good, Kriday. Bounded pool of 8, results accumulated after the pool so signalsCaptured/captured stop racing, and ordering is deterministic again. That is exactly the shape I was hoping for, and mapWithConcurrencyLimit is clean.

A few things before it can land (specifics inline):

• The new concurrency.ts has no test. Its whole reason to exist is two guarantees: never more than limit in flight, and output order == input order. Please add a test that proves both.
• This branch is not based on #41, so it still lists antigravity in HOOK_ADAPTERS and fails the adapter-wiring parity gate (3 failures). The #1 removal needs to be the base for this, not a sibling, so rebase this on top of #41.
• No version bump (user-facing), and the same CodeQL HIGH from the carried #39 base.

Merged with current main the only failures are those 3 parity ones, so once it is rebased on #41 and the concurrency test is in, this is basically there.

[Shreyan1]

Nice, clean worker pool. Two things: (1) this needs its own test, assert peak in-flight is never > limit (a worker that records a live counter) and that results come back in input order (resolve workers out of order to prove it). (2) minor sharp edge: if any worker rejects, Promise.all rejects and the remaining in-flight work is left dangling. Your current callers all catch inside the worker so it is fine today, but one line in the doc comment ("worker must handle its own errors, a throw abandons the pool") would save the next caller.

[Shreyan1]

This still lists antigravity, which is why the parity gate is red (3 failing tests). It is here because this branch predates #41's removal. Rebase #42 on top of #41 and this line becomes correct automatically, no manual edit needed.

[Shreyan1]

This is the fix and it is right: bounded to 8, and accumulating into captured after the pool restores the newest-file-last ordering the fan-out lost. One small thing, 8 is a magic number, a named const with a one-line "why 8" would help the next person.