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

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 `` with ``/`` pairs (`parse_glm_generated_message_ex`, ds4_server.c:5693).
- The Qwen 3.8 port in #990 adds `` with `` and ``, 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: `` structure, request temperature inside `` 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.