feat(llm): configurable analyzer fan-out concurrency via SKILLSPECTOR_MAX_LLM_CONCURRENCY (part of #303)

[Mark2Mac]

What

arun_batches fans out up to a hardcoded max_concurrency=10. On a rate-limited provider (free tiers with a low RPM) that burst guarantees 429s, and — per the method's own contract — 429'd batches are logged and omitted from the result. The scan silently loses analyzer coverage, including the security-critical semantic_security_discovery batch, while still emitting a full risk_assessment. A genuinely malicious skill can then read as clean.

This adds an env knob so users on such tiers can serialize the fan-out and stay under the limit:

SKILLSPECTOR_MAX_LLM_CONCURRENCY=1 skillspector scan ./skill/

• Default unchanged (10). An explicit max_concurrency= argument still wins.
• Invalid values fall back to the default; values < 1 clamp to 1.

Test

TestResolveMaxConcurrency: unset→default, valid→value, blank→default, invalid→default, 0→1. Full test_llm_analyzer_base.py suite green (116 passed); ruff clean.

Scope

This is the first of the three asks in #303 (configurable concurrency). The retry/backoff on 429 and surfacing a partial LLM pass in the verdict are larger changes left for separate PRs / discussion.

Refs #303

[rng1995]

[Automated SkillSpector Review]

Approved. The default remains 10, explicit arguments retain precedence, environment parsing handles invalid and blank values safely, and values below one are clamped. The focused resolver tests cover the new configuration behavior; no schema or security regression found.