fix(server): parse gemma's call:<verb>{} plain-text tool emissions

[easel]

Summary

Adds a sixth detection pattern to server/src/server/tool_parser.cpp::parse_tool_calls that recognizes the plain-text tool invocations gemma emits in chat-completion content — e.g. call:get_country_info{country: "France"}, call:execute-bead:read-file{path: "..."}, call:default_api:analyze_data{data: [...]}. None of the existing five envelope-shaped patterns (<tool_call>, bare <function=...>, <function=...(args)>, <tool_code>, bare JSON) match this shape, so a non-trivial slice of gemma's tool-using runs surfaces text-only to clients that expect structured tool_use blocks.

Why this matters

The 2026-05-30 gemma full bench (d9ecba6cc105-nvidia-geforce-rtx-3090-ti-gemma-full-2026-05-30-67f4) scored forge 0/30 because every row's iterations[0].output carried these call:<verb>{...} invocations as text content rather than structured Anthropic tool_use blocks. forge's WorkflowRunner expects a ToolCall payload and the row dies with ValidationError.

The downstream wiring is already in place: SseEmitter::accumulate calls parse_tool_calls, a non-empty result flips finish_reason to tool_calls, the Anthropic /v1/messages branch maps that to stop_reason="tool_use" with tool_use content blocks (server/src/server/http_server.cpp:2030-2090), and the OpenAI branch maps to choices[].message.tool_calls. The only gap was the parser.

What's in the new pattern

• Regex with sentinel anchor. (^|[\s,;:\(\[\{\}\)\]\>])call:([A-Za-z0-9_.:\-]+)\s*\{ — narrative I'll call:foo does match (whitespace before call:) but narrative.call:foo doesn't (no sentinel). } is in the sentinel set so back-to-back invocations call:a{...}call:b{...} both fire.
• Quote- and escape-aware brace scanner. Tracks {}/[] depth, skips over "..." / '...' / `...` string literals, honours \ escapes. Handles the multi-line nested-array shape from the snapshot.
• Relaxed-JSON arg parser. Strict json::parse first; on failure, rewrites the buffer to quote bare identifier keys and normalize single/backtick quoted strings to double-quoted, then retries. Malformed args drop only that one invocation — no crash, no false positives, surrounding calls keep working.
• Verb normalization. call:execute-bead:read-file → ToolCall name read-file (strips everything up to and including the last :).
• Pattern ordering. Inserted as pattern I can’t reproduce the prefill performance on the RTX 3090 #5, ahead of the bare-JSON sweep (now feat: add DFlash for Windows #6). This defends against call:outer{"name": "inner", "arguments": {}} where the bare-JSON sweep would otherwise pluck out the inner {"name": ...} as a spurious inner ToolCall. The brace span pattern I can’t reproduce the prefill performance on the RTX 3090 #5 records in removals shadows the inner JSON from pattern feat: add DFlash for Windows #6's view via the existing overlaps() check.
• Tool-allowed filter. Re-uses the existing tool_allowed(tools, verb) path so callers that pass a constrained tool list (forge) only get back tools they declared.

The full implementation plan, including the codex review and adjustments, lives at docs/experiments/server-call-verb-tool-parser-plan.md. Codex flagged the pattern-ordering hazard during review and the plan was revised before any code was written.

Test plan

14 new C++ unit cases in server/test/test_server_unit.cpp covering:

• Single bare call, back-to-back calls
• Namespaced verb (execute-bead:read-file → read-file)
• Mixed snake_case + kebab-case verbs across newlines
• Tool-allowed filter drops disallowed verbs
• Mid-prose narrative.call:foo{...} rejected (no sentinel char)
• Sure, I'll call:foo{...} accepted (whitespace sentinel)
• Malformed (unterminated brace) args → no crash, no ToolCall
• Inner {...} and } inside string values doesn't break the scanner
• Strict-JSON args (already-quoted keys) parse on the fast path
• Unquoted-key args parse on the relaxed path
• cleaned_text is properly scrubbed of the matched span
• Codex-requested: call:outer{"name": "inner", "arguments": {}} produces exactly one ToolCall named outer, not two
• Multi-line nested-array args mirroring default_api:analyze_data from the snapshot

All 14 pass in a standalone driver. CI will run them via the existing test_server_unit target wired in server/CMakeLists.txt.

Reverse-compat with the client-side fix

The forge client-side workaround _parse_plain_text_tool_calls shipping on feat/lucebox-docker (commit deba2fd) becomes redundant once a server with this fix is deployed. It stays in place as defense-in-depth for older deployed servers — the synthesized ToolCalls match what the server now produces, so the only cost is a few extra cycles in the client. Don't strip the Python fallback in this PR.

Out of scope

• Docker image rebuild + e2e bench re-run. The operator should rebuild the cuda12 image and confirm forge passes non-trivially without the client-side workaround once this merges.

🤖 Generated with Claude Code

[easel]

Folded into PR #285 — commits 12c50c0 (plan + codex review) and cdb8b9c (implementation) are now part of feat/lucebox-docker (tip 329f611). The C++ fix lands via #285 instead of as a separate PR against main.