fix(forge): synthesize tool_use from call:<verb>{} plain-text emissions

[easel]

Summary

Restores forge area from 0% pass-rate on the 2026-05-30 gemma full bench by fixing two stacked bugs in luce-bench/src/lucebench/areas/forge.py:

1. TextResponse(text=...) → ValidationError — the forge-internal TextResponse pydantic model's field is content, not text. Every send() call raised this immediately, so every row's error_type was ValidationError regardless of what the server actually returned. One-character fix (text= → content=).
2. Plain-text call:<verb>{...} emissions discarded — gemma emits structured tool calls as inline text inside the text content block (e.g. call:get_country_info{country: "France"}call:summarize{text: "..."}) rather than as Anthropic tool_use blocks. Even with Add Discord community link to README #1 fixed, forge would never have seen a tool call and would have nudged until max_iterations.

Empirical signal

From forge.json in the d9ecba6cc105-…-gemma-full-2026-05-30-67f4 snapshot: 30/30 rows failed with error_type = "ValidationError". Every iteration's tool_calls list is empty and output carries the raw call:<verb>{...} text. After this fix, that same response shape produces a list[ToolCall] that forge's WorkflowRunner consumes natively.

Approach

Client-side synthesis: when the response contains no tool_use content blocks but the text payload contains call:<verb>{...} invocations, parse the args as relaxed JSON (strict json.loads first, then a permissive pass that quotes bare keys) and synthesize ToolCall objects.

Why client-side, not server-side: the cleaner long-term fix is a server-side translation in chat_template.cpp / sse_emitter.cpp that converts call:<verb>{...} text into tool_use content blocks before they leave the server. That's a larger C++ change and out of scope for this PR — filed as follow-up for a future PR. The client-side path also future-proofs the bench for any other model that uses the same plain-text tool serialization (codex-mini, DDX bead executor, etc.) — same intent already recognized in lucebench.areas.agent's _CALL_INVOCATION regex.

Types

The forge LLMResponse contract is list[ToolCall] | TextResponse (see forge_eval/_forge/core/workflow.py). Synthesis stays within those existing types — no anthropic.types.Message construction needed, no SDK shape mimicry.

Stacked on PR #285

This PR's only changed files (luce-bench/src/lucebench/areas/forge.py and the new luce-bench/tests/test_forge_grader.py) live entirely inside #285's new luce-bench/ tree, which doesn't exist on main yet. The diff against main therefore includes all of #285's content; the substantive delta on top of #285 is two files.

Opened as a draft for now. Once #285 lands, this can be marked ready (the diff will collapse to just the two files). Alternative: change base to feat/lucebox-docker for a clean stacked-PR view.

Test plan

• New unit tests in luce-bench/tests/test_forge_grader.py cover: no pattern, single call, back-to-back calls preserving order, snake_case + kebab-case + namespaced verbs, strict-JSON args, malformed args dropped (no crash), unbalanced braces terminating scan, nested braces, strings containing } chars, and the reasoning-text stripper.
• Full pytest suite: 291 passed (up from 275 pre-change).
• Ruff lint clean on both touched files.
• Manual end-to-end: re-run forge area against gemma on sindri once this lands and confirm a non-zero pass rate.

[easel]

Folded into PR #285 — the forge fix (commit deba2fd) is now part of feat/lucebox-docker (current tip deb5adb). Closing this stacked PR; reviewable as part of #285.