fix(session): drop duplicate tool results in sanitizeToolCalls

[Sayt-0]

TL;DR

• Most of this is already fixed by fix: drop orphaned tool results on session resume #3001: sanitizeToolCalls drops orphaned tool results and injects placeholders for missing ones, keeping tool_use/tool_result balanced for strict providers (AWS Bedrock, including via a LiteLLM proxy). Related to Session resume via /sessions immediately fails with Bedrock ValidationException (toolResult/toolUse mismatch) #1676 and AWS Bedrock ValidationException: Protocol violation when assistant message contains both tool_calls and content #1593.
• This PR is a small follow-up that closes the one variant fix: drop orphaned tool results on session resume #3001 did not cover: a duplicate tool_result for the same tool_call_id.

Context

AWS Bedrock rejects any turn whose toolResult blocks outnumber the previous turn's toolUse blocks:

The number of toolResult blocks ... exceeds the number of toolUse blocks of previous turn.

Known structural causes and coverage:

Cause	Handled by	Status
Result with no matching tool_use (orphan)	sanitizeToolCalls (#3001)	covered
Result for a tool_use that never produced one (missing)	placeholder injection (#3001)	covered
Second result for the same tool_call_id (duplicate)	this PR	new

Change

• Drop a tool_result whose tool_call_id already received a result; keep the first.
• ~3 lines in sanitizeToolCalls, same spirit as fix: drop orphaned tool results on session resume #3001.

Test

• TestSanitizeToolCalls_DropsDuplicateToolResult (new)
• existing sanitize / orphan tests still pass

Notes

• Duplicates can surface from provider or streaming quirks (tool-call deltas re-emitting an id), so this completes the guard rather than fixing a confirmed in-the-wild trigger.

[docker-agent]

Assessment: 🟢 APPROVE

The change is correct and well-scoped. sanitizeToolCalls now drops duplicate tool_result messages for the same tool_call_id before the request reaches the provider, closing the last known structural cause of AWS Bedrock's toolResult/toolUse count mismatch (ValidationException).

Production logic (session.go): The new guard is placed after the existing orphan check and before resultIDs is updated, so it fires exactly when a second result for the same tool_call_id arrives within the same pending group. flushPending resets both maps, so the guard is naturally scoped to each turn — cross-turn duplicates are already handled as orphans. No logic errors found.

Test (sanitize_orphan_test.go): TestSanitizeToolCalls_DropsDuplicateToolResult exercises the new path end-to-end. The explicit count != 1 assertion is the right guard for this case. The assertToolPairingInvariant helper is appropriately scoped to orphan detection and the test compensates for its narrower scope with the direct count check.

No issues found in the changed code.