fix(runPool): don't report capped when pool is larger than workload (…

[hakanbaysal]

…#915)

capped was derived from effectiveConcurrency, which includes jobs.length in its Math.min(...). When fewer jobs than the requested concurrency were passed (e.g. runPool([j1, j2], { concurrency: 8 })), effectiveConcurrency dropped to the job count and capped became true even though no CPU or explicit cap was applied.

This surfaced in ctx_fetch_and_index as a misleading cap=N/Mcpu note implying the host CPU count throttled the batch, when the pool was simply larger than the workload.

Derive capped from the CPU/explicit cap only
(Math.min(requested, cpuCap) < requested), ignoring the job-count clamp. effectiveConcurrency is unchanged. Updates the doc comment and the runPool test that asserted the old behavior.

What / Why / How

Affected platforms

• Claude Code
• Cursor
• VS Code Copilot (GitHub Copilot)
• JetBrains Copilot
• Gemini CLI
• Qwen Code
• OpenCode
• KiloCode
• Codex CLI
• OpenClaw (Pi Agent)
• Pi
• Kiro
• Antigravity
• Zed
• All platforms

Test plan

Checklist

• Tests added/updated (TDD: red → green)
• npm test passes
• npm run typecheck passes
• Docs updated if needed (README, platform-support.md)
• No Windows path regressions (forward slashes only)
• Targets next branch (unless hotfix)

Cross-platform notes

Our CI runs on Ubuntu, macOS, and Windows.

• If touching file paths, verify forward-slash normalization on Windows
• If touching hook paths, verify no backslash separators
• Use path.join() / path.resolve(), never hardcode / separators
• Use event-based stdin reading — readFileSync(0) breaks on Windows
• Use os.tmpdir(), never hardcode /tmp