[Detection] Narrow images.generate batchCapable to a separate inlineParallelCapable flag #116

Summary

PR #110 marked openai.images.generate as batchCapable: true so the concurrency detector would not flag Array.from({length: n}).map(() => images.generate(...)) patterns. But this conflates two distinct API shapes:

1. True batch endpoints (/v1/batches, messages.batches.create, embedding multi-input) — accept an array of inputs in a single request.
2. Inline parallelism via API parameter (images.generate({ n: 4 })) — single request with a count parameter that produces N results.

The current batchCapable: true on images.generate is semantically loose. It works for the suppression we needed but blurs a meaningful distinction.

What to do

• Add a new AstCallMatch field: inlineParallelCapable?: boolean.
• Reclassify openai.images.generate from batchCapable to inlineParallelCapable in src/scanner/fingerprints/openai.json (or wherever the fingerprint lives).
• Update the concurrency detector's BOUNDED_REPLICATION guard logic to suppress on inlineParallelCapable as well as the existing Array.from({length:N}) regex check.
• Update the batch detector to keep firing for actual batch endpoints only.

Acceptance criteria

• Two distinct fingerprint flags exist (batchCapable for real batch APIs, inlineParallelCapable for n/count parameters).
• No regression to PR fix(detection): A3 + A5 — barrel re-exports + factory/DI/aliased clients (closes #75, #77) #110's concurrency-control suppression on images.generate.
• Suggestion text for true batch APIs ("use the batch endpoint") differs from inline-parallel suggestions ("use the n parameter").
• Future detector authors can reason about the two shapes separately.

Reference

Memory: a3_a5_pr_status.md — "batchCapable: true on images.generate is semantically loose…"