Recover DeepSeek tool calls from garbled DSML wrappers

[edwin-zvs]

Problem

Codex routed to DeepSeek V4 still ends turns without running a tool, even with #1185 in place. Reproduced live on a restarted daemon carrying that fix — function_call = 0, markup straight through into the transcript:

<｜｜DSML｜｜ollapse_tool_calls>
<｜｜DSML｜｜ollapse_tool_calls>
<｜｜DSML｜｜invoke name="exec_command">
<｜｜DSML｜｜tool_method>exec_command</｜｜DSML｜｜tool_method>
<｜｜DSML｜｜tool_params>
<｜｜DSML｜｜tool_command>find /Users/moon/construct/crates/daemon/src/router -name '*.rs' | wc -l</｜｜DSML｜｜tool_command>
</｜｜DSML｜｜tool_params>
</｜｜DSML｜｜invoke>
</｜｜DSML｜｜tool_calls>

This is a third markup shape, distinct from the two #1185 handles. Isolating the parser against it, each of three defects is independently fatal:

variant	tools recovered
exact live payload	0
wrapper corrected to tool_calls	0
canonical parameter name= children, garbled wrapper kept	0

1. Garbled opener — ollapse_tool_calls (a c eaten upstream) never matched the </…tool_calls> close, so the block failed to parse and StreamLift flushed it verbatim as assistant text.
2. Repeated opener, single close — parse_tool_calls_body hit the duplicate, failed, and break'd, discarding the invoke that followed.
3. Bespoke argument elements — tool_method / tool_params / tool_command instead of parameter name="…", which the harvester skipped, leaving empty arguments.

Approach

The spelling varies turn to turn, so chasing each shape with another exact-match arm will keep losing. Parsing is now recovery-oriented:

• close tags match on a shared suffix (min 4 chars, so unrelated tags can't collide) rather than exact equality
• a malformed opener is skipped rather than ending the scan
• unrecognized wrappers recurse instead of discarding their contents
• an invoke body harvests whatever children it carries: grouping elements (tool_params, parameters, args, …) flatten, tool_method supplies the tool name when the name attribute is missing, command-ish elements map onto cmd, and anything else becomes an argument keyed by its tag

Incomplete blocks still buffer rather than emitting a truncated call, so the streaming path can't invent a half-built tool.

Tests

Three added, all against the verbatim live payload:

• lifts_garbled_wrapper_and_bespoke_parameter_elements — batch path
• streams_garbled_wrapper_payload_into_a_tool_call — SSE path, chunked on char boundaries as JSON-decoded deltas always are
• incomplete_block_emits_no_tool_call — guards the recovery parsing against premature emission

cargo test -p construct-daemon: 640 passed, 0 failed. dsml.rs is fmt-clean; the crate has pre-existing fmt drift in unrelated files that this PR deliberately leaves alone.

Binary

Only crates/daemon is touched; the code ships in the construct binary (the daemon runs the router in-process):

/Users/moon/construct/.claude/worktrees/dsml-generic-tool-parse/target/debug/construct

No user-visible TUI surface changes, so no recording.

Follow-up, not fixed here

The loose _command arm from #1185 maps to a tool named shell, but Codex in these sessions exposes exec_command. A successful lift of that variant may still produce a function_call the harness can't dispatch. Fixing it properly means giving the lift access to the request's tool list, which is a larger change than this one.