fix(vllm): parse tool_call function arguments before applying the chat template

[pos-ei-don]

Problem

Multi-turn tool calling fails with a 500 once the client sends back an assistant message containing tool_calls:

TypeError: Can only get item pairs from a mapping.

_messages_to_dicts() parses the outer tool_calls JSON array but leaves function.arguments as a JSON-encoded string (that's the OpenAI wire format). Chat templates like Qwen3's iterate over arguments as a mapping, so apply_chat_template() blows up. vLLM's own OpenAI-compatible server parses arguments into a dict before rendering the template.

Fix

After decoding the outer array, decode each function.arguments string into a dict. Strings that aren't valid JSON are left untouched.

Tested

On an NVIDIA DGX Spark (GB10, ARM64), cuda13-nvidia-l4t-arm64-vllm backend, Qwen3-Coder with use_tokenizer_template: true: without the patch every second-turn tool call 500s; with the patch multi-turn tool calling works (finish_reason: tool_calls, correct arguments round-trip).

[pos-ei-don]

Re-verified this today against the current quay master backend build (master-nvidia-l4t-cuda-13-arm64-vllm) on the DGX Spark, this time with a small model so it's easy to reproduce: Qwen/Qwen3-0.6B, use_tokenizer_template: true, and a two-turn tool-call conversation (assistant message with tool_calls, then a tool result).

One detail worth knowing for review: the bug only triggers with chat templates that iterate over arguments as a mapping — e.g. the Qwen3-Coder template does {%- for args_name, args_value in tool_call.arguments|items %} and fails with TypeError: Can only get item pairs from a mapping (HTTP 500). The base Qwen3 template just runs arguments | tojson, which happens to work with the string, so the bug stays invisible there. That's probably why this hasn't been reported more widely.

With this patch applied on top of the same build: the identical request returns 200 and the template renders the parsed arguments correctly.