Fix qwen3_coder tool parser crash on non-numeric int/number params

[robertlangdonn]

Relates to #1236.

Summary

qwen3_coder._convert_param_value coerces parameter values to int()/float() based on the schema type, but those calls are unguarded. When a model emits a non-numeric string for an integer- or number-typed field, the coercion raises ValueError, which aborts parsing and drops the entire tool call.

from mlx_lm.tool_parsers import qwen3_coder

tools = [{"function": {"name": "f", "parameters": {"properties": {"x": {"type": "integer"}}}}}]
out = "<function=f><parameter=x>2026-01-15</parameter></function>"
qwen3_coder.parse_tool_call(out, tools)
# ValueError: invalid literal for int() with base 10: '2026-01-15'
# (a "number"-typed field raises the analogous float() error)

Fix

Fall back to the raw string when int()/float() coercion fails, matching how the object/array branch already tolerates values that are neither valid JSON nor valid Python literals. A slightly mistyped argument is far better than dropping the call.

This complements #1310 / #1239, which guard the ast.literal_eval branch of the same function; the int()/float() branches were the remaining unguarded coercions (I noted this while reviewing #1310). Together they close the crash class described in #1236.

Testing

• New test_qwen3_coder_unparseable_numeric_params: a non-numeric value for an int/number field falls back to the raw string, while valid numeric values are still coerced to int/float.
• Full tests/test_tool_parsing.py suite passes.