fix(agent): keep model focused after failed tool calls

[syf2211]

Summary

When a tool call fails, the agent can pivot to unrelated tasks instead of retrying or asking for clarification. This PR adds a static system-prompt guardrail and injects a per-round focus hint after failed tool results.

Motivation

Fixes #18 — reported scenario: after browser_navigate 404, the model ignored the user's correction and started reading unrelated local files via MCP filesystem tools.

Changes

• Add isToolFailure() helper detecting built-in Error: results, MCP errors, and non-zero run_command exits (excludes doom-loop Refused: guidance)
• Add TOOL_FAILURE_FOCUS_HINT injected into API messages after any failed tool round
• Wire injection into TUI (repl.ts), headless agent, and ACP agent loops
• Add system-prompt bullet under Tool policy
• Unit tests for failure detection

Tests

• bun test src/agent/tool-failure-focus.test.ts — 7 pass
• bun test — 452 pass
• bun run typecheck — pass
• bun run build — pass

Notes

This is a prompt-level guardrail, not a hard tool-category block. It follows the same injection pattern as the existing doom-loop recovery guidance. No server-side routing changes required.

[github-actions]

🤖 KlaatAI Review Bot (powered by Klaatu, advisory only — a maintainer makes the real call)

Issue match
Partially addresses #18: implements suggested fixes #1 (system-prompt guardrail) and #2 (per‑round focus hint injection). Does not implement #3 (CLI‑side heuristic for tool‑category pivots) or #4 (tier routing). The acceptance criteria (reproduce & confirm behavior) are not directly tested.

Test coverage
isToolFailure is well‑covered by 7 unit tests in tool-failure-focus.test.ts. Missing: no test verifies that TOOL_FAILURE_FOCUS_HINT is actually injected into the message sequence after a failed tool round in ACP, headless, or TUI flows, nor that it is omitted when all tools succeed. The new system‑prompt bullet is also untested.

Correctness concerns
The injection logic in acp/agent.ts, headless-agent.ts, and repl.ts looks sound — the hint is appended only when at least one tool in the round fails, using the same isToolFailure helper. One edge: isToolFailure treats any result starting with "Error" as a failure, which could catch legitimate command output that begins with “Error” (e.g., a log line). This is probably intentional but may produce false‑positive hints. No other risky interactions seen.

Verdict
Needs human judgment call on whether the prompt‑only approach is sufficient without integration tests or the heuristic suggested in #18 (tool‑category pivot after failure).

_{This is an automated review to help triage faster, not a gate. Nothing here blocks merging.}