Add ToolOrphanRepair capability

[DouweM]

Summary

• Implements ToolOrphanRepair, a capability that sanitizes message history to fix orphaned tool calls and results before each model request
• Injects synthetic ToolReturnPart / BuiltinToolReturnPart for calls without matching results, strips ToolReturnPart / RetryPromptPart whose tool_call_id doesn't match any call, and handles trailing responses and empty request edge cases
• Exports as from pydantic_harness import ToolOrphanRepair

Refs: pydantic/pydantic-ai#4728

Test plan

• 25 tests covering all repair scenarios: orphaned calls, orphaned returns, orphaned builtin calls, trailing responses, empty requests, warnings, multi-turn conversations, and no-op passthrough
• pyright strict mode: 0 errors
• ruff lint + format: clean

🤖 Generated with Claude Code

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[DouweM]

Originally posted by @DouweM in #132 comment (PR was recreated)

Audit vs prior art: ToolOrphanRepair

Worth adding now:

• Duplicate tool_call_id deduplication
• Debug-level logging of specific repairs (not just count)

Follow-up opportunities:

• Integration with Compaction to catch orphans created by summarization

[DouweM]

Originally posted by @adtyavrdhn in #132 comment (PR was recreated)

Notes from comparing with Hermes, Pi-mono, and Mastra

Looked at how other frameworks handle the same problem. A few things worth noting:

Synthetic returns should be marked as errors
Pi-mono marks injected results with isError: true so the model knows the tool didn't actually succeed — it's not a normal result, it's a "this never ran" signal. We can't do this yet because ToolReturnPart doesn't have an is_error field. That's tracked in pydantic/pydantic-ai#4363. Once that lands, the synthetic returns here should set is_error=True.

Duplicate tool_call_id handling
Already flagged in the audit comment. The current set-based matching means if two calls share an ID (provider bug, frontend-generated IDs), only one synthetic return gets created and the other call stays orphaned. Worth adding detection + a warning at minimum.

Tool ID sanitization is not this PR's job
Hermes has an explicit _sanitize_tool_id() that replaces non-[a-zA-Z0-9_-] chars for Anthropic compliance. That's a provider adapter concern — belongs in pydantic-ai's Anthropic model, not in history repair. Mentioning it here just because it causes the same symptom (Anthropic 400s).

Errored/aborted turns — framework handles it (mostly)
Pi-mono skips entire responses with stopReason === "error". Pydantic-ai already handles finish_reason='length' (raises IncompleteToolCall) and auto-generates tool call IDs if missing, so partial tool calls aren't a concern for this capability. finish_reason='error' responses do silently enter history though — that's a framework-level gap, not something for here.