fix(dashboard): test Responses nodes on /v1/responses, not chat completions (#13070)

[ntdatt812]

Fixes #13070.

The defect

detectTestKind() reads the provider node's apiType, but only maps it to audio, rerank and embeddings. There is no Responses branch, so every text model on a node configured with apiType: "responses" falls through to:

return postChatCompletion(buildInternalChatRequest(testBody, signal, connectionId));

which is hardcoded to ${INTERNAL_ORIGIN}/v1/chat/completions.

A Responses-native upstream can answer 200 to that while carrying nothing a Chat Completions reader recognises, so the dashboard marks the model red with Provider returned HTTP 200 but no text content — while the same model answers normally through /v1/responses.

What changed

• detectTestKind() now also reports isResponses. It is last in the chain, after audio / rerank / embeddings: a Responses-typed node can still host an embedding or rerank model, and those endpoints were already right for it. Losing that ordering would break working setups instead of fixing a broken one.
• New buildInternalResponsesRequest(), carrying the same health-check bypass headers as the chat and rerank builders.
• The probe body is { model, input, max_output_tokens }. Responses ignores max_tokens, which would let a reasoning model spend the whole default budget before emitting visible text.
• The probe is non-streaming on purpose. extractComboTestStreamResult() understands Chat Completions deltas and the output_text / output[] shapes, but not Responses stream events (response.output_text.delta), so a streamed probe would read as empty — the very failure being fixed. The reader is passed !isResponses && streamChat so it takes the JSON path.

No reader change was needed: extractComboTestResponseText() already handles output_text and output[]. Only the request side was ever wrong.

Evidence

Six new tests in tests/unit/responses-node-model-test-13070.test.ts, plus the four existing detectTestKind deep-equal assertions extended with the new field.

The wiring is pinned, not just the classification. My first version of the last test asserted on the request that reached globalThis.fetch, and it was worthless: for a Responses node the router translates a Chat Completions body into Responses shape before it leaves, so the upstream body carries input either way. That test stayed green with the dispatch reverted. It now reads the call log, which records the internal endpoint path — the same field the report used as evidence.

Two-way mutation, run locally:

Mutation	Result
none (the branch as submitted)	6 / 6 pass; full model-test-runner.test.ts 32 / 32
remove the if (isResponses) dispatch, keep detectTestKind	1 fail — the call-log test; the other five stay green
detectTestKind always returns isResponses: false	2 fail — classification and call-log

Not covered

The Responses streaming path. The probe avoids it rather than teaching extractComboTestStreamResult() the Responses event shape; that is a larger change and a separate one. If you would rather the probe stream, say so and I will send the reader work instead.