fix(analyzer): bound file analysis workers

[omribz156]

Closes #8046

Reason for Proposed Changes

• The analyzer currently starts one goroutine per candidate file.
• On very large repositories, that can create tens of thousands of goroutines during "Preparing Scan Assets" and trigger the thread-exhaustion crash reported in the issue.

Proposed Changes

• Replace per-file goroutine spawning with a bounded worker pool.
• Size the pool from GOMAXPROCS, capped at 128 workers and never larger than the candidate file count.
• Add unit coverage for the worker-count helper.

Verification

• go test ./pkg/analyzer -count=1
• go test ./pkg/scan -run "Test.*Analyze|Test.*Init|Test.*Prepare" -count=1
• git diff --check

This was implemented with Codex assistance, with the final patch kept focused and manually reviewed.

I submit this contribution under the Apache-2.0 license.

[devAL3X]

I have tested this fix against my repo where the issue was occurring - the issue is no longer reproducible

[cx-artur-ribeiro]

Hi @omribz156,
Thanks for the contribution 🙏 !

I've also verified this resolves the thread-exhaustion crash cleanly and the bounded-pool wiring (channel-fed workers, wg.Add/wg.Done moved to the pool level) is correct, including preserving the existing unwanted-channel drain race handling in computeValues that I've introduced earlier this year.

One addition I would propose: the added test to analyzer_test only covers analyzerWorkerCount as a pure function. Nothing exercises Analyze() itself under a file count that forces multiple files through a single pooled worker, so a regression that reintroduced go a.worker(...) per file would pass this test suite untouched.
I suggest adding the test bellow alongside it, in pkg/analyzer_test.go.

Let me know what you think and thanks again for your help improving kics!
Thank you as well @devAL3X for exposing the problem and taking the time to explain what the problem was as well.

P.S: I can address the changes on my side and close this PR once we merge the changes, mentioning both the issue and the original pull request.

[cx-artur-ribeiro]

Commits do need to be signed in order for any pull request to be merged.

If this is something that you cannot achieve on your side, I will open the PR on my side and tag you, as well as the pull request and related issue as well.

Let me know if you could sign the commits on your side @omribz156.

[cx-rui-araujo]

Hi @omribz156,
Thanks for the contribution 🙏 !

The bounded pool implementation looks good.
I have one suggestion: could we make the 128 worker cap configurable via a MaxAnalyzerWorkers field in the Analyzer struct? This would let users who consume the package adjust it for their specific environments.
I added comments with the suggestion in case you wanna commit via GitHub.
P.S: I can address these changes on my side in a different PR after merging this one (so you can resolve my comments if you feel so).

Let me know what you think and thanks again for your help improving KICS!
Also, as Artur said, thank you as well @devAL3X for exposing the problem and taking the time to explain what the problem was as well.

[cx-rui-araujo]

LGTM 🐐