fix(bridge): sanitize orphaned tool results in v2 adapter

[serrrfirat]

Summary

• sanitize V2 bridge chat history before sending it to LLM providers
• reuse the shared sanitize_tool_messages helper from the LLM module
• add regression tests covering both orphaned and valid action-result sequences in the bridge adapter

Root cause

The V2 LlmBridgeAdapter converted ThreadMessage values directly into ChatMessage values and forwarded them to the provider without calling sanitize_tool_messages(). When thread history contained an orphaned action result, Anthropic rejected the request with error 2013 because the tool_result no longer had a matching preceding tool call.

Impact

• orphaned tool results are rewritten into normal user-visible messages before provider submission
• valid tool call / tool result pairs are preserved unchanged
• V2 Anthropic threads can recover from compaction, checkpoint restore, or pause/resume histories that would previously get stuck

Validation

• cargo fmt --all --check
• cargo test bridge::llm_adapter::tests --lib

Closes #1950

[gemini-code-assist]

Code Review

This pull request introduces a sanitization step for tool messages within the LlmBridgeAdapter by calling sanitize_tool_messages before provider execution. This ensures that orphaned action results are appropriately handled. Additionally, new unit tests have been added to verify the correct processing of both orphaned and matched action results. There are no review comments to address, and I have no further feedback to provide.

[ilblackdragon]

Automated review — LGTM with minor notes

TL;DR: Well-scoped bug fix. Correctly isolates orphaned tool results at the adapter boundary using the existing sanitize_tool_messages helper. Good test coverage. Ready to merge after addressing the visibility nit below.

Findings

#	Severity	File:Line	Issue	Suggestion
1	Low	src/llm/mod.rs:59	pub(crate) use sanitize_tool_messages re-export — per CLAUDE.md "No pub use re-exports unless exposing to downstream consumers"	Use the direct path use crate::llm::provider::sanitize_tool_messages at the sole call site in llm_adapter.rs
2	Low	src/bridge/llm_adapter.rs:51	let mut chat_messages but only mutated once via sanitize	Either document the in-place rationale or accept &[ChatMessage] and return a new vec
3	Low	Test structure	All three new async tests use CapturingProvider that always returns Ok(...); no negative path	Add a test where the provider returns an error after sanitize, to verify error propagation is intact

Strengths

• Root cause clearly identified (missing sanitize_tool_messages call in adapter path → Anthropic error 2013)
• Smart reuse of existing helper (DRY)
• Uses tracing::debug!() — respects the TUI logging convention
• Tests cover both complete() and complete_with_tools() paths

Open questions

1. Is the pub(crate) re-export intentional for future callers, or can it stay private to the provider module?
2. Are there other adapter paths (streaming, retries, failover) that could also receive corrupted message sequences and should call sanitize?