BYOK (Mistral): 422 Unprocessable Entity on the request after a tool call — assistant message sends both `content` and `tool_calls`

Start at runAgenticLoop in app.js and reproduce the follow-up request with a Mistral BYOK provider using devstral-latest or zai-glm-5-2. Inspect the assistant.message and session.error records in ~/.copilot/session-state//events.jsonl, along with the OTel entry, to trace the rejected payload. Done means the agentic loop accepts preamble-plus-tool-call responses and provider error details are surfaced; tool-call ID handling is a secondary concern.

Describe the bug

With a BYOK (custom model) provider configured against the Mistral API (https://api.mistral.ai), model discovery works fine and the first model call of a session succeeds. But as soon as the model emits a short preamble sentence and a tool call in the same assistant message, the next request in the agentic loop fails immediately with:

422 Unprocessable Entity

The session then dies with session.error / errorContext: "model_call" and the UI just shows "Unprocessable Entity" with no detail.

Root cause: Mistral's API rejects an assistant message that carries both a non-empty content field and tool_calls — it requires either content or tool_calls, but not both. Copilot replays the assistant turn with both fields populated when the model prefixes its tool call with text, so the follow-up request (the one carrying the tool result) is invalid.

This is reproducible and correlates perfectly across three local sessions, one of which works:

Model (same Mistral provider)	First assistant message	Result
mistral-medium-latest	"content": "" + toolRequests	✅ works
devstral-latest	"content": "I'll help you…" + toolRequests	❌ 422
zai-glm-5-2	"content": "I'll analyze this repository…" + toolRequests	❌ 422

The only difference is whether the model happened to emit a preamble alongside the tool call — which is not something the user can control, so any Mistral BYOK model is effectively unusable for agentic work.

Secondary issue (same provider, will bite next): Mistral validates tool_call_id as exactly 9 alphanumeric characters. Native Mistral models return compliant ids (KkQq9A6FI, GrkR6lLMv), but the third-party model zai-glm-5-2 hosted on the same endpoint returns vLLM-style ids such as chatcmpl-tool-aae20b13990bb75a, which Mistral's own request validator then rejects on the follow-up request. Normalizing/remapping tool call ids per-provider would fix that class too.

Affected version

1.0.85 (win32-x64; also reproduced on 1.0.80)

Steps to reproduce the behavior

1. Configure a BYOK custom model provider pointing at https://api.mistral.ai with a valid API key. Model discovery succeeds and the models appear in the picker.
2. Start a session with devstral-latest (or any Mistral-hosted model that emits preamble text before a tool call).
3. Send any prompt that causes a tool call, e.g. analyze this repo for me.
4. The first model call succeeds and the tool executes (visible in the UI), then the session immediately fails with 422 Unprocessable Entity.

Expected behavior

The agentic loop should keep running. When targeting a provider that disallows an assistant message with both content and tool_calls, the client should split them into two messages (or drop/relocate the preamble text) rather than sending a payload the provider rejects.

Secondarily, the surfaced error should include the provider's response body — "422 Unprocessable Entity" with no detail makes this essentially undiagnosable without digging into OTel files.

Additional context

Local evidence (Windows 11, x86_64, Windows Terminal, PowerShell):

~/.copilot/session-state/<id>/events.jsonl — the failing assistant message:

{"type":"assistant.message","data":{"model":"zai-glm-5-2",
 "content":"I'll analyze this repository for you. Let me start by exploring its structure and key files.",
 "toolRequests":[{"toolCallId":"chatcmpl-tool-aae20b13990bb75a","name":"rename_branch",
 "arguments":{"name":"analyze-repo-structure"},"type":"function"}]}}

…followed a fraction of a second later by:

{"type":"session.error","data":{"errorType":"query","message":"422 Unprocessable Entity","statusCode":422}}
{"type":"hook.start","data":{"hookType":"errorOccurred","input":{"error":{"message":"\"422 Unprocessable Entity\""},"errorContext":"model_call","recoverable":true}}}

~/.copilot/otel/copilot-otel.jsonl confirms the first call succeeded and the second failed:

gen_ai.client.token.usage   provider=openai  server.address=api.mistral.ai
  gen_ai.request.model=<provider-id>/zai-glm-5-2  gen_ai.response.model=zai-glm-5-2
  input=48464  output=34                       <- first call, OK

gen_ai.client.operation.duration  error.type=SessionTurnError
  gen_ai.operation.name=invoke_agent  server.address=api.mistral.ai
  duration=0.158s (no gen_ai.response.model)   <- second call, 422

The stack trace in the error hook is unhelpful (napi_register_module_v1 frames only) on current builds; on 1.0.80 it pointed at runAgenticLoop in app.js.

Reference for the Mistral constraint: langchain-ai/langchain#21196 — "Assistant message must have either content or tool_calls, but not both."