fix(mistral): Validate tool_calls type before iterating

[elizabetht]

maybe_serialize_tool_calls() calls next() on the raw tool_calls value without verifying it is an iterable. When tool_calls is a string or other non-iterable type, the pydantic ValidatorIterator tries to validate each character as a dict, producing a confusing error.

Add an explicit type check before iterating: if tool_calls is not a list, tuple, or iterator, raise a clear ValueError. Also skip the message entirely when tool_calls is None instead of creating an empty tuple iterator.

Purpose

Fixes #34225

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

The pull request effectively addresses a critical issue where maybe_serialize_tool_calls could encounter runtime errors when processing tool_calls values that are iterable but not direct iterators (e.g., lists or tuples). The introduction of explicit type checking and proper handling for None values significantly enhances the function's robustness. The new test cases are comprehensive and cover various scenarios, including valid lists, None values, and invalid types like strings and integers, which is excellent for ensuring the fix works as intended.

[juliendenize]

Hey thanks for contributing, i think the issue is just having a proper error message, i did this pr that should fix it and is a bit less verbose
#34438