[Mistral Grammar] Fix tool and reasoning parsing.

[juliendenize]

Purpose

When Mistral models are served with --tool-call-parser mistral and a mistral_common-compatible tokenizer (tekken/v11+), since this PR, tool parsers has a grammar-based approach: adjust_request injects a Lark grammar from mistral-common's grammar factory into structured_outputs. This grammar constrains the model output to follow valid Mistral tool-call formatting at the decoding level.

However, the PR only handled the grammar injection which broke the vLLM tool-parsing. This PR makes the serving layer actually use the Mistral tool parser and reasoning parser to parse the grammar-constrained output, rather than falling through to the generic vLLM tool-call parsing paths which don't understand Mistral's format.

Test Plan

The branch adds:

• Unit tests in tests/tool_parsers/test_mistral_tool_parser.py for is_mistral_grammar_path, build_non_streaming_tool_calls, and the extract_maybe_reasoning_and_tool_streaming state machine.
• E2E tests in tests/tool_use/mistral/test_mistral_tool_calls.py covering auto, required, none, no-tools, and tool-response-followup scenarios for ministral-3b — both streaming and non-streaming.

# Unit tests
pytest tests/tool_parsers/test_mistral_tool_parser.py -v
# E2E tests (requires GPU + model download)
pytest tests/tool_use/mistral/test_mistral_tool_calls.py -v

Test Result

The tests pass

---

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.

[juliendenize]

Adding a bunch of comments for context

[juliendenize]

Was introduce by me when adding reasoning_effort="none", it was a bad idea as sometimes model would fail to not generate or include_reasoning can have side effects on the parsers.

[juliendenize]

This is due to a regression that was recently introduced, i'd need to check if this fix is sound on Monday and if so i'll open another pr just for that

[juliendenize]

needed to know if the grammar is active without ambiguity

[juliendenize]

this is not the cleanest maybe but this is the best i found to have a non-intrusive way of knowing if reasoning should be expected by the grammar.