Resolves #17008 Refs #17000 Refs #16998

Un-stacked: #17002 merged at 07:14Z, so this now targets dev directly. The three #16999 commits are in dev and were dropped from this branch by git rebase --onto origin/dev; the four commits here are its own. Carried action RA-4 (retarget + full exact-head CI) is therefore discharged.

Problem

ask_knowledge_base dispatches through a serializing admission queue, so two asks arriving seconds apart are served one after the other regardless of how much idle capacity the serving endpoint has. Traced at 271bb132d8:

SearchService.mjs:176        this.model = buildChatModel({…})
buildChatModel.mjs:160       return chatRequestQueue.enqueue(…)      // openAiCompatible = ask's default provider
buildChatModel.mjs:110       chatRequestQueue = sharedLocalChatRequestQueue    // process-wide default
InteractiveBatchQueue.mjs:2  "A single-lane request scheduler that runs async tasks one at a time"

At the measured ~43 s per ask, the second returns near ~86 s. So provisioning a dedicated endpoint or a replica pool without addressing admission yields idle replicas behind a queued second ask — and the symptom reads as "the model is slow" rather than "the queue admitted one". The constraint is admission, not capacity, and #17000's operator requirement (two asks 2 s apart, both served) cannot be met by deployment alone.

Approach

• InteractiveBatchQueue gains an optional capacity, default 1 — the original single-lane behaviour exactly, so every existing consumer is byte-identical. The #active boolean became a #running counter, because a boolean can only say "a lane is busy" and cannot represent a freed slot among several.
• askSynthesis.maxParallel (default 1) in the existing node — no second config node.
• buildAskRequestQueue() reads that leaf at the use site, constructs the queue, and SearchService injects it.

Three decisions worth pushing on

1. Slot-filling is SYNCHRONOUS on purpose. Two enqueue calls in the same tick must both be admitted when capacity allows. An await in the drain would let the first task's dispatch delay the second — reintroducing serialization while still reporting a capacity above one, which is the worst outcome because the number would look right.

2. Ask gets its OWN queue instance, not a raised capacity on the shared one. Capacity belongs to the consumer that has its own endpoint; raising it on the process-wide queue would hand concurrency to every other local chat consumer as a side effect. Blast radius measured rather than assumed: the only two buildChatModel callers repo-wide are SearchService (KB process) and memory-core's SessionService (a different process), so the "process-wide" queue never serialized them against each other and ask is the only chat consumer in its process. No contention changes hands.

3. The capacity is read at the use site and the CONSTRUCTED QUEUE is injected — never the number. ADR 0019 B5 forbids passing AiConfig values into another consumer's config, and C1 (zero-tolerance) forbids buildChatModel importing AiConfig, since the provider layer is not a thread-entrypoint. So the capacity cannot reach buildChatModel by either route; an injected collaborator is not a threaded config value, which is what keeps this inside B5. The injection parameter is now documented as a production injection point rather than left labelled a test seam — the explicit argument #17000 asked for instead of quiet reuse.

No builder-local fallback. maxParallel is read plainly. A || 1 would be dead code — the declared default inherits to every overlay (the generated config.mjs is a thin singleton declaring no data of its own) — and masking a real config break as "serialized" is the quiet failure, since a deployment that meant to run parallel asks would silently keep serializing them.

Contract Ledger

Deltas

ai/provider/InteractiveBatchQueue.mjs — optional parallel capacity, default 1; #running counter; synchronous slot-filling; slot released before re-draining. ai/provider/buildChatModel.mjs — the queue parameter re-documented as a production injection point (JSDoc only). ai/mcp/server/knowledge-base/configBase.mjs — the maxParallel leaf inside the existing askSynthesis node. ai/services/knowledge-base/SearchService.mjs — buildAskRequestQueue() + injection at the buildChatModel call. ai/scripts/lint/config-leaf-parity.json — parity snapshot, in the same commit per the lint's instruction.

Evidence: L2 (queue arms mutation-verified in both directions, the original 7 as the default-capacity control, plus a composition arm proving the queue reaches buildChatModel) → L2 sufficient for #17008, whose ACs are all decidable in-process. No residuals: the endpoint, exclusivity, attribution, model decision and L3 witness are #17000's scope, not deferred work from this close-target.

Test Evidence

npx playwright test .../InteractiveBatchQueue.spec.mjs .../SearchService.spec.mjs \
                   .../searchService.askContextBudget.spec.mjs .../SessionService.buildChatModel.spec.mjs
  57 passed

Mutation-verified in both directions — a green suite is not evidence the arms would catch a defect:

The original 7 queue arms pass unchanged, including "never runs two tasks concurrently", which now serves as the default-capacity control: if capacity 1 ever stopped being the old behaviour, that arm is what says so.

Review round 2 — all four required actions

• Capacity reachable from a deployment. NEO_KB_ASK_MAX_PARALLEL was absent from every file under ai/deploy/ — verified with a positive control, since the sibling NEO_KB_ASK_MODEL appears in three. Now carried through docker-compose.yml and docker-compose.dev.yml. This was the same defect I had diagnosed on the miniSummary window leaves hours earlier and then committed here.
• Mutation-sensitive composition witness. buildAskChatModelOptions() returns the exact options object handed to buildChatModel, and an arm asserts the queue that arrives there. Removing chatRequestQueue now fails exactly that arm (1 failed / 20 passed in that spec); before, it left the whole suite green.
• Truthful close edge. Carved #17008 for what this PR fully resolves; #17000 keeps the endpoint, exclusivity, attribution, model decision and L3 witness, which need host provisioning this PR does not perform. No requirement is assigned back to a ticket this PR declares resolved.
• Retargeted to dev + full exact-head CI. #17002 merged; this branch was rebased onto dev, and all 20 hosted checks are green at bba7d992f0.

Post-Merge Validation

• L3 witness, once a dedicated endpoint exists: one long-running Dream/graph call on the full-power lane, then two asks 2 s apart. Judged on each ask's persisted queue_wait_ms (providerActivityLedger.mjs:357-360 already returns queue wait and execution time as separate columns) — the second ask's wait must collapse to near zero. A wait ≈ the first ask's duration is the serialized-admission signature.
• Confirm no summarisation or graph call reaches the ask endpoint during that witness.

⚠️ Not valid against the external plane until it carries accfdb0c1a (#16943) — pre-fix rows there report a real queue as absent, so a queue_wait_ms read would encode the fixed defect rather than measure admission.

Residual-Owner: #17000

Authored by @neo-opus-vega