GLM (and soon Qwen) tool-call syntax gets no decode-time protection; DSML does

[titan550]

ds4 now has two tool-call languages. A third is in progress.

• DeepSeek models use DSML, in three dialects (dsml_syntaxes, ds4_server.c:6507).
• GLM models use <tool_call> with <arg_key>/<arg_value> pairs (parse_glm_generated_message_ex, ds4_server.c:5693).
• The Qwen 3.8 port in Add an experimental Qwen 3.8 Flash Next port on Metal #990 adds <tool_call> with <function=...> and <parameter=...>, with a new render and parse stack.

Only DSML has decode-time protection. dsml_decode_tracker_update (ds4_server.c:6725) classifies each position as structure or payload. Structure decodes greedy. Payload keeps the request temperature.

GLM has no equivalent. GLM structure decodes at the request temperature, so a sampling accident can corrupt a tag. The server detects this only after the fact and asks the model to retry ("Tool error: invalid GLM tool call", ds4_server.c:11056). Each retry costs a full round trip. The Qwen syntax will have the same gap. The tag sets are also close neighbors: <tool_call (GLM, Qwen) is a one-character near-miss of <tool_calls (the plain DSML dialect), so the scanners must tell three languages apart across a one-byte difference.

I would like to write a GLM tracker that gives GLM the same protection: greedy inside <tool_call> structure, request temperature inside <arg_value> payload. The GLM tags are single vocab tokens, so the tracker is small. Doing this will naturally factor out the common shape of the two trackers, and the Qwen port could then reuse that shape instead of adding a fourth bespoke path. The same classification point is also what tool_choice: "required" needs — the server rejects that option today for lack of it (ds4_server.c:4757).

The DSML tracker tests from #997 pin the existing behavior, so the DSML side would not change.

Is this direction acceptable? If yes, I will send the GLM tracker as a PR.