deepseek-v4-pro on opencode-go /responses fails on any multi-turn request (flash & official API both work)

Env: Windows 11, Codex with wire_api = responses via cc-switch → https://opencode.ai/zen/go/v1, model deepseek-v4-pro. I retried right after the 0813 model update and the problem is still there.

What happens: First turn in a fresh conversation is fine. From the second turn on, as soon as the request includes the previous assistant reply, it returns 400.

Errors I've seen (two variants):

Error from provider (Console Go): Upstream request failed: [invalid_request_error] Invalid assistant message: content or tool_calls must be set

and earlier:

Failed to deserialize the JSON body into the target type: messages[4]: missing field `id` at line 1 column ...

Same request with deepseek-v4-flash returns 200, and going straight to the official DeepSeek API (api.deepseek.com/v1/responses) also returns 200. So it looks like Console Go's conversion from Responses to its internal messages format doesn't handle pro's assistant message history properly.

Minimal repro (same body, pro → 400 / flash → 200):

curl -s https://opencode.ai/zen/go/v1/responses \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "input": [
      {"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]},
      {"type":"message","role":"assistant","content":[{"type":"output_text","text":"hello"}]},
      {"type":"message","role":"user","content":[{"type":"input_text","text":"how are you?"}]}
    ]
  }'

Swap model to deepseek-v4-flash with the exact same body and it returns 200.

This seems related to #42090, #42091 and #36354 — Console Go validates pro's message/tool format stricter than flash and rejects the standard Codex format. Would be great if this could be fixed, or if pro's /responses could be routed to the native upstream the way flash was.

Start at the /responses handling and its conversion into the internal messages format, using the minimal curl request as the reproduction. Compare deepseek-v4-pro with deepseek-v4-flash and review related issues #42090, #42091, and #36354. Done means the multi-turn pro request returns successfully without the missing id or empty assistant-content errors.