KG-596 Fix thought signature on tool call with gemini 3.0

[mltheuser]

Motivation and Context

Related to: KG-596

Gemini 3.0 models enforce stricter validation of thoughtSignature for function calls. When the model returns parallel tool calls, only the first call in a turn receives a thoughtSignature. On subsequent turns, the API expects this signature to be echoed back exactly. Without proper handling, multi-turn agentic conversations with parallel tools fail with cryptic API errors.

The Problem: The GoogleLLMClient wasn't preserving thoughtSignature across turns, and wasn't correctly re-grouping parallel tool calls/results when constructing requests—leading to malformed conversation structures that newer Gemini models reject.

How It's Solved

1. Preserve thoughtSignature: When processing model responses, we now extract the thoughtSignature from GooglePart.FunctionCall and store it in Message.Tool.Call.metaInfo.metadata. When building subsequent requests, we restore it.

2. Correctly batch parallel tool calls/results: The createGoogleRequest function now uses a buffering strategy to re-group interleaved messages. The key insight: if a tool call has a thoughtSignature, it starts a new turn; if it doesn't, it's a parallel call in the same turn. This lets us batch calls into a single model role GoogleContent and results into a single user role GoogleContent, as the API requires.

3. Clean, idiomatic implementation: The buffering logic uses a when expression to make the three states explicit (new turn, starting fresh, parallel call), keeping the code readable and maintainable.

Breaking Changes

None. This is a backward-compatible fix that enables correct behavior with Gemini 3.0+ while remaining compatible with earlier models.

---

Type of the changes

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tests improvement
• Refactoring

Checklist

• The pull request has a description of the proposed change
• I read the Contributing Guidelines before opening the pull request
• The pull request uses develop as the base branch
• Tests for the changes have been added
• All new and existing tests passed

Additional steps for pull requests adding a new feature

• An issue describing the proposed change exists
• The pull request includes a link to the issue
• The change was discussed and approved in the issue
• Docs have been added / updated

[kpavlov]

Thank you, @mltheuser, very useful fix. Brings value
I added a couple of comments on test scenarios, and making it more defensive.

[antoniibelyshev]

Thank you! Looks almost ready. I saw a couple issues which might need attention.

1. The reasoning inside a function call seems to be duplicated: it is added as a separate Reasoning message, and then also as part of the function call.
2. Probably, it's better to not introduce a new field in the metaInfo, and just use the Resoning messages as delimiters indicating where a new api response starts.
   Not sure about both of the points though. I'm open for a discussion here.

[mltheuser]

Thank you everyone for the in-depth review. I have switched to the pattern where we store thought signatures in reasoning messages as suggested by @antoniibelyshev and I have extended the tests as suggested by @kpavlov (your point about verifying the structural logic (especially for parallel calls) was also spot on)

[antoniibelyshev]

Thank you! LGTM

[jay-anbaric]

Is there somewhere official that the public can track what will be release? We are keen to see this fix being part of the next release as this is stopping us from using gemini 3 models with tool calls.