fix(console): serve GLM Go models through the Responses API - #51303

Issue for this PR

Fixes #51306.

Addresses the GLM-5.3 and GLM-5.3-Flash cases in #44910 and the missing SSE item lifecycle in #40171. The fixes in #45013, #45050, #45081, and #45085 cover OpenCode's LLM client adapter; this change is at the public Go API route.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

For glm-5.3 and glm-5.3-flash, the Go /v1/responses route translates the incoming Responses request into Chat Completions, then passes it through the existing Go authentication, inference routing, and billing handler. Other models keep the current route.

The translation preserves top-level instructions, conversation history, function call IDs and outputs, function tool definitions, and tool choice. Streaming Chat output is converted into ordered Responses SSE events, including message and function-call item lifecycles, item response_id fields, the final response, usage, cached input tokens, and reasoning token counts when supplied by the upstream. The rewritten request preserves Codex's session-id and thread-id headers; the legacy handler also uses them as session-affinity fallbacks.

This is scoped to the two GLM models that the current Go catalog lists on Chat Completions. It does not change their provider configuration or the separate inference service.

How did you verify your code works?

From packages/console/app on RHEL 10:

• bun test test — 49 passed
• bun typecheck — passed

Prettier and oxlint passed on the changed route, adapter, and test files. Regression tests cover multi-turn function-call replay, native header forwarding, nonstreaming usage, interleaved streaming tool calls, event order, cached tokens, and an empty upstream stream.

With a test-only Go API key, I also probed the currently deployed Go API from RHEL 10 before applying this patch. Both GLM models were listed by /models and returned HTTP 200 from /chat/completions (including usage and cached-token data). The same models returned HTTP 503 from /responses in both streaming and nonstreaming requests with Endpoint is unavailable. A forced tool-call request on GLM-5.3-Flash also returned HTTP 503. This reproduces the affected route in production.

I then made a live GLM-5.3-Flash Chat Completions streaming tool call and a follow-up turn with the tool result; both returned HTTP 200. Feeding each captured Chat stream through this adapter produced a completed Responses event sequence with the function call or assistant message, usage, and a terminal [DONE]. The patched public route has not been deployed, so this validates the adapter against real Go streams but is not a live end-to-end verification of the route.

A separate live Chat Completions request built from Codex CLI's actual function-tool schemas also returned HTTP 200 with a complete stream.

Finally, Codex CLI 0.155.1 was run with an isolated temporary provider configuration and a local mock endpoint serving SSE generated by this adapter. It accepted the stream, executed a function call, sent a second Responses request containing matching function_call and function_call_output IDs, then completed successfully. The captured requests contained both native session-id and thread-id headers. No production Codex configuration was changed.

Screenshots / recordings

Not applicable to an API change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR