fix(litellm): avoid duplicate streamed tool-call content

[thesynapses]

Link to Issue or Description of Change

1. Link to an existing issue:

• Closes: LiteLLM Streaming Content Duplication in Tool Call Responses #3697
• Supersedes: Fix: LiteLLM Streaming Content Duplication in Tool Call Responses #3698, which GitHub would not allow reopening after its stale head was replaced

Problem:

LiteLLM streaming responses emit text as partial events, then repeat the same text in the final aggregated tool-call response. This duplicates planning/reasoning content in clients and conversation history.

Solution:

Set content=None on the final aggregated tool-call message. The text remains available through the already-emitted partial responses, while the final response contains only the function call.

The branch has been rebuilt as one commit directly on current main; the unrelated changes and merge commits from #3698 are no longer present.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

361 passed in tests/unittests/models/test_litellm.py

The regression test verifies that streamed text is emitted through partial responses and the final aggregated response contains only the function-call part.

Formatting and import-order checks pass with the repository-pinned Pyink and Isort versions.

Manual End-to-End (E2E) Tests:

Not run; the adapter behavior is covered by the existing mocked LiteLLM streaming fixture and the focused regression assertion.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have added tests that prove my fix is effective.
• New and existing LiteLLM unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

A maintainer reconfirmed the diagnosis on #3697 and requested that #3698 be rebased. GitHub returned HTTP 422 when reopening #3698, including after temporarily restoring its recorded head, so this PR carries the requested clean rebase.