fix(sessions): close out unanswered tool calls before the error reply (tool-batch wedge)

[Aaronontheweb]

Red-first TDD. This PR currently contains only a failing test that
reproduces the bug — CI is expected to be red. The fix lands in a follow-up
commit; the test flips green once it does.

The bug

This is the root cause of the self-hosted/DeepSeek session wedges from the
tool-call investigation. When a parallel tool batch partially fails,
LlmSessionActor.FailCurrentTurn appends the "I encountered an error executing
a tool" assistant reply (via SessionState.AddErrorReply) without first
writing a tool-result for the unanswered call(s). History becomes:

assistant  tool_calls=[A, B]
tool       result A
assistant  "I encountered an error executing a tool"   ← wedged here
tool       result B   (synthetic, appended on a later turn)

Strict OpenAI-compatible providers (DeepSeek, Qwen, vLLM) require an assistant
tool_calls message to be immediately followed by a contiguous run of
tool-result messages answering every tool_call_id. The wedged error reply
breaks that run, so every subsequent request returns HTTP 400
insufficient tool messages following tool_calls and the session is stuck until
a new user turn rebuilds history.

The failing test

ToolBatchHistoryWedgeTests drives a two-call parallel batch where one call
throws in InterpretToolCall — the only pre-try seam in
SessionToolExecutionPipeline that escapes to ToolExecutionFailed, so the
healthy call is recorded first (a Task.WhenAll invariant). It then asserts, on
the history assembled for the next provider request, that the assistant
tool_calls message is immediately followed by tool-results for every call
id.

Today it fails with:

Expected [call-A,call-B] but the contiguous run covered [call-A].
Assembled roles: system -> system -> user -> assistant -> tool -> assistant -> tool -> user

— the assistant(tool_calls) -> tool(A) -> assistant(error) -> tool(B) wedge,
exactly as the provider would see it.

The fix (follow-up commit)

Make FailCurrentTurn close out the unanswered tail tool batch (synthesize
tool-results for the still-open call ids, reusing the existing
ParkedToolBatchHistory / ToolBatchAbandoned machinery) before appending
the error reply — so history is well-formed at rest for any provider, and no
mid-batch tool failure can wedge a session.

[Aaronontheweb]

LGTM