[Bugifx] [Qwen3CoderTool] Restore supports_required_and_named for required tool_choice

[chaunceyjiang]

Purpose

Follow of #40894

As a widely used tool parser, Qwen3Coder should still support supports_required_and_named = True at this stage.

Otherwise, tool_choice="required" no longer works correctly now.

I think this should continue to be properly supported at least before structural_tag is enabled by default.
@sfeng33 @aarnphm @Seven-Streams @aarnphm @bbrowning

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.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[gemini-code-assist]

Code Review

This pull request removes the supports_required_and_named attribute from the Qwen3CoderToolParser class. The review feedback indicates that this change introduces a conflict with the parser's XML-based structural tags, as it forces the system to use a JSON extractor that is incompatible with the XML output, leading to failures when tool_choice is set to 'required'.

[bbrowning]

Agree we don't want to regress here for user's that have not opted into the strict tool calling enforcement via Xgrammar.

[cjackal]

A thought - it feels like to integrate xgrammar's stag templates better with more model archs, major refactoring of output parser (like RFC #32713) is necessary.

xgrammar clearly moves toward a "unified" parser; it supports full-time structured decoding (contrary to the in-the-middle-of-tool-calling structured decoding that vllm currently takes) and each stag template binds tightly to the target model, and this kind of movement is not unique to xgrammar, smg as another example - any token parser framework that works atop of token-in-token-out inference engine would naturally look like that.

And vllm's current parser system that guarantees independency of reasoning and tool call parser makes it hard to develop such a unified parser design without a sort of backward incompatibility - one instance is this bugfix, and supporting a request-level thinking on/off alongside forced stag is also quite messy in its current form (currently stag is bound to a tool call parser, which has little info on reasoning parser counterpart). There are several places in the scheduler code that handle reasoning / tool call boundary which explicitly assume that reasoning / tool call parser are independent.

If a backward incompatibility is unavoidable, it might be better starting to write "vllm parser V2" that lies in separate codepath from the vllm parser status quo and put xgrammar stag feature to parser V2 I think.