common : fix tool call type detection for nullable and enum schemas

[sacredvoid]

Overview

Fixes #21316

The Gemma4 dict parser and the tagged parser both only check type_v.is_string() when figuring out if a tool argument is a string. This breaks for schemas that use nullable types like "type": ["string", "null"] or enum fields without an explicit "type" key, both of which are pretty common in OpenAPI/Home Assistant setups.

When the type isn't recognized as "string", the parser falls through to the raw-value path and captures <|"|> delimiter tokens as literal text, which is how you end up with output like "domain": "[<|\"|>light<|\"|>]" instead of "domain": "light".

The fix is straightforward:

• Extract the effective type from type arrays (grab the first non-null entry)
• Infer string type from enum fields that have string values
• Applied to both build_tool_parser_tag_gemma4_dict and build_tool_parser_tag_tagged since they share the same pattern

All existing tests pass (test-chat-auto-parser: 56 tests, 373 assertions, 0 failures; test-chat: all passed).

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES - used Claude Code to explore the codebase, trace through the parser logic, and identify the root cause. The fix itself is a simple type-detection improvement that I reviewed and tested manually.

[pwilkin]

Can you add tests please? Looks legit to me, might want @aldehir @CISC @ngxson to take a look.

[ngxson]

Yes I'll test it tomorrow

[aldehir]

This should be common functionality implemented in common/json-schema-to-grammar.cpp by common_schema_info. There is already logic to identify if a particular schema reduces to a string, which already handles the ["string", "null"] and enum cases. It needs to be extended to produce a type name if that's what we need.

[sacredvoid]

Thanks for looking at this. @aldehir good call - I didn't realize common_schema_info already handles the schema reduction for ["string", "null"] and enum cases. Makes way more sense to extend that rather than patching each parser separately.

I'll rework it to add a type name getter (or similar) to common_schema_info and have both parsers use that. Will add tests as well.

One thing I want to check: for the enum case where there's no explicit "type" key but all values are strings, does common_schema_info already reduce that to string? Or would that need new logic too?

[aldehir]

It does infer types if there is no type property. I say hold off until we get input from other maintainers.

I might have jumped the gun and perhaps this surgical change might be good for now and we can address the general case later.

[ngxson]

I wasn't been able to test this on my side, but the added case in test-chat.cpp seems correct.

[pwilkin]

I'd say we utilize this fix now and possibly generalize later.