fix: drop empty tool_calls arrays on assistant messages (strict providers 400)

[prateekranka]

Problem

DeepSeek (and other strict OpenAI-compatible providers) rejects assistant messages carrying tool_calls: [] with an HTTP 400 (tool_calls must be a non-empty array or absent).

This happens in sanitize_api_messages: the pre-call sanitizer dedups duplicate tool_call_ids across assistant/tool pairs. When every tool call in a turn was a duplicate id, the dedup left tool_calls: [] on the assistant message — and the earlier sanitizer pass that drops empty arrays had already run, so the empty array reached the wire.

Fix

• When dedup removes all calls from a message, drop the tool_calls key entirely instead of leaving [].
• Add a final pass before send that strips any surviving tool_calls: [] on assistant messages (belt-and-braces for other paths that can produce the same shape).

Verification

Reproduced locally with DeepSeek as the primary provider: 400 on tool_calls: [] before the change; long-running sessions with duplicate-id turns proceed cleanly after. Existing sanitizer behavior for non-empty calls is unchanged.

[spfcraze]

This was generated by AI during triage.

Summary:
This PR re-implements a fix already open in #64345 and #77377 — both change the identical kept_tcs branch of sanitize_api_messages to drop the tool_calls key when dedup removes every call — and the root cause is tracked in #74101, #64335 and #76862.

Problems:

• fix(sanitize): drop tool_calls key when dedup removes all calls #64345 (open since 2026-07-14) makes the same change to the same branch in agent/agent_runtime_helpers.py, with a regression test.
• fix(sanitize): drop tool_calls key when dedup removes all calls (fixes empty-array 400 class) #77377 (open since 2026-08-03) makes the same change and references Bug: sanitize_api_messages dedup pass writes tool_calls: [] — HTTP 400 on DeepSeek/OpenAI #64335, fix(sanitize): drop tool_calls key when dedup removes all calls #64345, sanitize_api_messages dedup re-introduces tool_calls: [] after empty-array sanitizer (DeepSeek HTTP 400) #74101 and Bug: pre-call sanitizer 去重后 tool_calls 变成空数组导致 provider 报 400 #76862 in its description.
• The description here links none of the sibling PRs or the tracked issues.

Solution:
Link #64345 and #77377 in the description so the three open implementations of this fix are visible together.

---

Checked against 8c70072 — the PR head when this was written — and 2446c8b, main at the moment this comment was posted.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #64345: both remove tool_calls after dedup empties an assistant turn, preventing strict-provider empty-array HTTP 400s.

[teknium1]

The empty-tool_calls 400 class this PR targets is now fixed on main via #86654, which closes all three chokepoints: the sanitize_api_messages dedup pass drops the key instead of writing [] (salvaged from #64345 by @liuhao1024, earliest fix for that site), the repair_message_sequence merge pops the stale key at the source (salvaged from #77944 by @webtecnica), and ChatCompletionsTransport.convert_messages() strips empty/null tool_calls at the wire boundary (salvaged from #72591 by @TurgutKural, earliest fix for that site). Your analysis matched the merged approach — thank you for the contribution; closing in favor of the merged class fix with credit to the earliest filer per site.