Fix MessageWindowChatMemory to drop orphaned ToolResponseMessages after window eviction

[suryateja-g13]

Problem

`MessageWindowChatMemory` truncates the message list from the head when the window size is exceeded. However, it does not account for the structural constraint that every `ToolResponseMessage` must be preceded by an `AssistantMessage` containing the matching tool-use call.

When the window evicts exactly enough messages to remove an `AssistantMessage` that contained a tool-use block, the corresponding `ToolResponseMessage` is left at the start of the retained list — as an orphan with no preceding tool call. Sending this to an LLM causes an API error (e.g. Anthropic returns `400: tool_use block must be followed by tool_result`).

Reproduction scenario

```
Window limit = 3, per-add saves (as done by MessageChatMemoryAdvisor):
add([UserMsg1]) → [UserMsg1]
add([AssistantMsg(tool)]) → [UserMsg1, AssistantMsg(tool)]
add([ToolResponseMsg]) → [UserMsg1, AssistantMsg(tool), ToolResponseMsg] ← at limit
add([AssistantMsg_final]) → trim 1 → [AssistantMsg(tool), ToolResponseMsg, AssistantMsg_final]

Next turn:
add([UserMsg2]) → trim 1 → [ToolResponseMsg, AssistantMsg_final, UserMsg2]
^^^ orphaned — no preceding tool_use → Anthropic 400
```

Solution

After the standard head-truncation, scan the retained list for any `ToolResponseMessage` entries that appear before the first non-system, non-tool-response message. Drop all of them — they are orphans whose `AssistantMessage(tool_use)` partner was evicted.

```java
private static List dropOrphanedToolResponses(List messages) {
// skip leading SystemMessages (always preserved)
// drop all consecutive ToolResponseMessages at the head
// (their AssistantMessage partner was evicted by the window trim)
}
```

Changes

• `MessageWindowChatMemory.java`: call `dropOrphanedToolResponses()` after head-truncation
• `MessageWindowChatMemoryTests.java`: four new tests

Tests

All existing 18 tests continue to pass. Four new tests added:

• `orphanedToolResponseIsDroppedWhenToolUseEvicted` — single orphan
• `multipleConsecutiveOrphanedToolResponsesAreAllDropped` — two back-to-back orphans from a multi-tool-call turn
• `toolPairPreservedWhenBothFitInWindow` — complete pair survives eviction
• `systemMessagePreservedWhenOrphanedToolResponseDropped` — system message stays at position 0
• `loneOrphanedToolResponseWithMaxMessagesOneResultsInEmptyHistory` — edge case: single orphan leaves empty history

Known limitation

`dropOrphanedToolResponses` only catches orphans created by FIFO head-first eviction — the only eviction strategy currently implemented. If a future strategy evicts an `AssistantMessage(tool_call)` from a non-leading position, its `ToolResponseMessage` would not be detected.

After orphan drop, the conversation may start with an `AssistantMessage` (clean text, no tool calls) if the user message that preceded it was also evicted in the same cycle. This is a separate concern — the specific error reported in #5940 (`tool_result` with no matching `tool_use`) is fully addressed here.

Closes #5940

[suryateja-g13]

Flagging for maintainer attention — the original issue (#5940) has had active discussion recently that reinforces why this fix is needed.

Key findings from the thread:

• The recommended Spring AI pattern (disableInternalConversationHistory() + MessageChatMemoryAdvisor at default order) does store tool pairs in memory on every tool iteration — this is by design, confirmed by AbstractToolCallAdvisorIT
• There is no workaround available to users short of placing MessageChatMemoryAdvisor outside the tool loop (a non-obvious deviation from the recommended pattern)
• The orphan issue is reproducible in production with any tool-heavy conversation once the window starts sliding — the original author hits it every few hours with maxMessages=100

This fix is the correct place to handle it — in MessageWindowChatMemory itself, transparently, without requiring users to change their advisor configuration.