v1.13.16-xml-parser: Anthropic <invoke> support + unknown-tool recovery hints

Two-part fix for the model-emitted XML drift the v1.13.15-codecontext-synth
investigation surfaced (1 raw <invoke> leak observed out of 190 qwen3.6
turns — qwen3.6-35b-a3b-mxfp4 drifts to the Anthropic format when prompted
as an Architect-style agent because Claude Code documentation in its
pre-training corpus uses that shape).

## Parser extension

xml-parser.ts now recognizes BOTH XML tool-call flavors:

  - Qwen/Hermes:   <tool_call><function=NAME>...<parameter=K>V</parameter>...</function></tool_call>
  - Anthropic:     <invoke name="NAME"><parameter name="K">V</parameter></invoke>

Both route through the same synthetic-id xml_call_${idx} ToolCall path.
extractToolCallBlocks() and partialXmlOpenerStart() handle both openers
(<tool_call> and <invoke...) so partial buffers don't get prematurely
flushed during streaming.

The existing Qwen parser was tightened to tolerate whitespace around `=`
(<function = name>, <parameter = key>...) so a stray space doesn't get
absorbed into the function name. Name capture is non-whitespace,
non-`>`.

## Unknown-tool recovery hint

New tool-suggestions.ts exports levenshtein() + suggestToolName() +
formatUnknownToolError(). When tool-phase.ts:executeToolCall receives a
toolCall.name that isn't in TOOLS_BY_NAME, the error returned to the
model now includes a "Did you mean: X?" hint based on Levenshtein
distance ≤3 or substring match against Object.keys(TOOLS_BY_NAME).
Targets the qwen3.6 drift to read_file → suggest view_file. Applies to
all unknown tool names, not just <invoke>-derived ones — at the
dispatch layer we no longer know which format produced the call, and
the extra signal is harmless for Qwen-derived calls.

## Test coverage

xml-parser.test.ts: 46 tests, all green. Covers both parsers
(well-formed, malformed, multi-parameter, nested-content), the
partial-opener detector for both flavors, the unified extraction
helper, and the unknown-tool error formatter.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/server/src/services/inference/tool-phase.ts

@@ -4,6 +4,12 @@ import { PathScopeError } from '../path_guard.js';
 import { TOOLS_BY_NAME } from '../tools.js';
 import { maybeFlagForCompaction } from './payload.js';
 import { insertParts, partsFromAssistantMessage, partsFromToolMessage } from './parts.js';
+// v1.13.16: richer unknown-tool error so the model can self-correct when it
+// drifts to a Claude Code tool name (e.g. read_file → suggest view_file).
+// Applies to all unknown tool names, not just <invoke>-derived ones — at the
+// dispatch layer we no longer know which format produced the call, and the
+// extra signal is harmless for Qwen-derived calls.
+import { formatUnknownToolError } from './tool-suggestions.js';
 import type {
   InferenceContext,
   StreamResult,
@@ -26,7 +32,11 @@ async function executeToolCall(
 ): Promise<{ output: unknown; truncated: boolean; error?: string }> {
   const tool = TOOLS_BY_NAME[toolCall.name];
   if (!tool) {
-    return { output: null, truncated: false, error: `unknown tool: ${toolCall.name}` };
+    return {
+      output: null,
+      truncated: false,
+      error: formatUnknownToolError(toolCall.name, Object.keys(TOOLS_BY_NAME)),
+    };
   }
   const parsed = tool.inputSchema.safeParse(toolCall.args);
   if (!parsed.success) {