fix(sse): accept Responses API custom tool_choice (#13122)

[diegosouzapw]

Closes #13122

Root cause

open-sse/translator/request/openai-responses.ts translates a Responses API tool_choice
object in an if/else if chain. It handled type: "function", type: "local_shell", and
type: "allowed_tools", but any other type — including type: "custom" — fell through to a
generic unsupportedFeature() throw (400, unsupported_feature). Codex CLI's
wire_api = "responses" sends tool_choice: {type: "custom", name: "..."} to force a call to
a declared custom/freeform tool (e.g. functions__exec), so every such request was rejected —
even though the same request's tools[].type === "custom" declaration is already accepted and
normalized into a Chat {input: string} function schema a few lines above (fixed under #1007).

The issue's other two complaints (custom tool calls coming back as function_call with JSON
arguments instead of custom_tool_call with raw input) are already fixed on this branch by
#1007 and covered by tests/unit/translator-openai-responses-custom-tool-1007.test.ts — no
code change was needed for those; they were a side effect of Reproduction 1's 400 in the
reporter's session.

Fix

Added a tcType === "custom" branch, mirroring the existing local_shell case: when the
Responses tool_choice has type: "custom" and a name, translate it to Chat's
{type: "function", function: {name}}, forcing the same declared custom tool by name. A
{type: "custom"} choice with no name (not spec-compliant per the Responses API) still falls
through to the existing unsupported_feature throw.

Regression test

tests/unit/responses-custom-tool-choice-13122.test.ts (new file, 3 tests):

RED (unfixed code):

✖ Responses -> Chat: tool_choice.type = 'custom' forces the named custom tool instead of throwing (#13122)
  Error: Unsupported Responses API feature: tool_choice type 'custom' is not supported by omniroute
      at unsupportedFeature (.../open-sse/translator/request/openai-responses/helpers.ts:83:17)
      at openaiResponsesToOpenAIRequest (.../open-sse/translator/request/openai-responses.ts:772:13)
  statusCode: 400,
  errorType: 'unsupported_feature'

GREEN (fixed code):

✔ Responses -> Chat: tool_choice.type = 'custom' forces the named custom tool instead of throwing (#13122) (36.597223ms)
✔ Responses -> Chat: tool_choice.type = 'custom' without a name still throws unsupported_feature (#13122) (2.982036ms)
✔ OpenAI -> Responses: forced custom tool call round-trips as custom_tool_call with raw input (#13122) (10.004306ms)
ℹ tests 3
ℹ pass 3
ℹ fail 0

Gates run

• DATA_DIR=$(mktemp -d) node --import tsx/esm --test --test-force-exit tests/unit/responses-custom-tool-choice-13122.test.ts → 3/3 pass
• DATA_DIR=$(mktemp -d) node --import tsx/esm --test --test-force-exit tests/unit/translator-openai-responses-custom-tool-1007.test.ts tests/unit/responses-chat-translation-gaps.test.ts tests/unit/responses-additional-tools.test.ts → 31/31 pass (existing coverage of the same translator, unaffected)
• npx eslint --suppressions-location config/quality/eslint-suppressions.json open-sse/translator/request/openai-responses.ts tests/unit/responses-custom-tool-choice-13122.test.ts → clean, exit 0
• npm run check:open-sse-typecheck → clean, exit 0
• node scripts/check/check-file-size.mjs → no violation on touched files (1 pre-existing violation on open-sse/utils/stream.ts, untouched by this PR — base drift)
• node scripts/check/check-complexity.mjs → OK
• node scripts/check/check-cognitive-complexity.mjs → OK
• node scripts/check/check-test-discovery.mjs → OK, new test file discovered

Existing tests aligned

None — no existing assertion encoded the old buggy custom → throw contract; the new branch is
purely additive and all 31 tests in the touched files' existing suites pass unmodified.