Resolve DSML tool names against the tools a request offered

[edwin-zvs]

Follow-up to #1189, which flagged this as the remaining gap.

Problem

DSML command markup carries no tool name at all, so the lift has to invent one. #1185 invented shell. Codex offers exec_command.

A function_call naming a tool the harness never advertised is dropped, so the turn ends without running anything — the same visible outcome as markup that was never lifted. The recovery parsed the markup correctly and still lost the call.

Fix

TranslationContext already flows from request emission to both response decoders, so it's the natural carrier: record the request's tool names there, and resolve a recovered name against them before emitting ToolStart.

Resolution is deliberately conservative, in order:

1. name was actually offered → keep it
2. single case-insensitive match → use it
3. shell-ish guess (shell, exec_command, bash, run_command, run_terminal_cmd, execute_command) and exactly one shell-ish tool on offer → use it
4. exactly one substring match either direction (exec → exec_command) → use it
5. otherwise → leave the recovered name alone

Ambiguity is not resolved. Dispatching the model's command into the wrong tool is worse than the harness rejecting a name it doesn't know, so two plausible candidates means no substitution. An empty offered list means "no information" — never "the request had no tools".

Tests

Seven added, covering each rung and the end-to-end path:

• resolves_a_shell_guess_onto_the_offered_shell_tool — the live mismatch
• keeps_a_name_the_request_actually_offered
• keeps_the_recovered_name_without_an_offered_list
• refuses_to_guess_between_ambiguous_candidates
• resolves_a_unique_substring_match
• leaves_an_unrelated_name_alone
• streams_loose_command_markup_as_the_offered_shell_tool — markup in, dispatchable tool out

cargo test -p construct-daemon: 647 passed, 0 failed. Added lines are fmt-clean; the crate's pre-existing fmt drift is left alone.

Scope

decode_full_response for the chat dialect now takes the context (it previously took only the body), and Gemini's TranslationContext literal picks up the new field via ..default().

Not fixed here

Argument keys still come from the markup, not the tool's schema — a tool whose parameter is spelled something other than cmd can be called with the wrong key and fail just as quietly. Fixing that means plumbing the schemas through too and matching against their properties; it deserves its own change rather than being bolted on here.

Binary

crates/daemon only — ships in construct:

/Users/moon/construct/.claude/worktrees/dsml-resolve-tool-names/target/debug/construct