fix(#1644): enforce Anthropic tool sequencing and filter sub-agent messages

[aheritier]

Summary

Fixes #1644 — unexpected tool_use_id found in tool_result blocks errors when using Anthropic models with multi-agent sessions.

Includes #1680 (provider/anthropic: enforce tool sequencing, remove self-repair/validation).

Root Causes

Two independent issues caused orphaned tool_result blocks to reach the Anthropic API:

1. Sub-agent message interleaving in parent session

GetMessages() included all messages from session items regardless of which agent they belonged to. When sub-agent messages were present in the parent session (from historical persistence bugs or from in-memory sub-session expansion), they were interleaved between the parent agent's tool_use (transfer_task) and its tool_result.

This broke Anthropic's strict tool sequencing requirement because:

• Sub-agent assistant messages with their own tool_calls appeared between the root's tool_use and tool_result
• Sub-agent tool_calls referenced tool_use_ids whose tool_results only existed in the sub-session, not the parent

2. trimMessages could orphan tool results

The old trimMessages removed individual messages without treating [assistant(tool_calls) + tool results] as atomic blocks. Trimming an assistant message left its tool results behind, creating invalid sequences.

3. Silent self-repair masked the real problem

The Anthropic provider had validateAnthropicSequencing/repairAnthropicSequencing that inserted synthetic tool_result blocks to paper over broken sequences. This prevented fast failure and made the underlying issues harder to diagnose.

Changes

Layer 1 — GetMessages() sub-agent filtering (237b0069)

Filter messages by agent name: skip any message whose AgentName is set and doesn't match the current agent. User messages (empty AgentName) and the current agent's messages pass through.

Layer 2 — trimMessages rewrite with atomic tool blocks (03a585a7)

Rewritten to use a reverse-scan approach that:

• Treats [assistant(tool_calls) + tool results] as atomic blocks — kept or dropped together
• Validates tool result IDs match the preceding assistant's tool call IDs
• Drops orphaned/mismatched tool results
• Protects user messages from trimming (merged from fix(#1863): preserve user messages in trimMessages to prevent session derailment #1864)

Layer 3 — Anthropic convertMessages strict validation (03a585a7)

Replaced the validate-then-repair approach with strict enforcement during message conversion:

• Tracks pendingToolUseIDs and validates each tool_result against them
• Returns immediate errors for orphaned tool results, missing tool results, ID mismatches
• Removed validateAnthropicSequencing, repairAnthropicSequencing, and all related helpers
• Same cleanup applied to the Beta API path

Testing

• Updated existing trimMessages tests to reflect atomic-block and user-message-protection semantics
• Added TestTrimMessages_AtomicToolBlocks and TestTrimMessages_OrphanedToolResults
• Added TestGetMessages_FiltersSubAgentMessages for sub-agent message filtering
• All Anthropic provider conversion tests updated for strict error returns

[aheritier]

/review

[docker-agent]

Review Summary

Found 1 critical issue: Inconsistent orphan tool result handling between beta and regular converters violates the PR's goal of strict validation.

[docker-agent]

Beta converter silently drops orphan tool results while regular converter returns error

When pendingToolUseIDs == nil (indicating no preceding assistant tool_use in the current window), the beta converter silently skips tool messages without validation (lines 112-120). However, the regular converter in client.go:457-459 explicitly returns an error for this exact scenario:

if pendingToolUseIDs == nil {
    return nil, fmt.Errorf("unexpected tool result without preceding tool_use (tool_use_id=%q)", messages[i].ToolCallID)
}

Issue: This inconsistency violates the PR's stated goal of "strict enforcement" and "removing self-repair". Orphan tool results are a protocol violation per Anthropic's requirements — they should be caught and reported in both converters, not silently dropped in one.

Impact: Malformed message sequences (e.g., assistant with no tool calls followed by tool results) pass through undetected in the beta API path, potentially causing downstream issues or silent data loss.

Recommendation: Change the beta converter to return an error like the regular converter does, maintaining consistent strict validation across both API paths.