Errored tool part in history produces unpaired tool_calls on strict OpenAI-compatible providers (e.g. Moonshot Kimi) #49911

Bug

When session history contains an assistant message with parallel tool calls where one call errored, opencode builds a request for OpenAI-compatible providers that includes the assistant tool_calls but no matching tool response for the failed call. Strict endpoints (Moonshot) reject the request; lenient ones (Anthropic, opencode Zen) accept it.

Provider error (from Moonshot):

an assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: skill:0, glob:1, glob:2, read:3, read:4

Repro (from real session DB, opencode 1.18.31)

1. In a session, have the model issue parallel tool calls where one fails. In my case one assistant message held 5 calls — skill, glob, glob, read, read — with the skill part ending in status error:
   <tool_use_error>Unknown skill: customize-opencode</tool_use_error>
2. Continue the session (switch models freely — Claude, opencode models all keep working with this history).
3. Switch to a strict OpenAI-compatible model (here kimi-code-plan-cn/k3, Moonshot endpoint) and send any message.
4. The request fails with the error above. Retrying in the same session keeps failing (history still contains the poisoned turn); a fresh session works.

Expected

Errored tool parts should be converted into paired tool response messages (e.g. carrying the error text as content, as the OpenAI API allows), or the dangling tool_call should be dropped — so the payload validates on strict endpoints.

Notes

• The synthesized call IDs in the provider error (skill:0, glob:1, …) suggest the converter rebuilds IDs per request rather than reusing stored call IDs.
• Same history accepted by Claude API and opencode provider — only strict OpenAI-compatible validation trips.
• opencode 1.18.31