[Chat] Preserve a ToolCall's signature across the MessageNormalizer round trip

[RomainLvr]

Q	A
Bug fix?	yes
New feature?	no
Docs?	no
Issues	–
License	MIT

MessageNormalizer loses a ToolCall's signature on the round trip: it is neither written on normalization nor restored on denormalization. The same class already round-trips Thinking::getSignature(), so tool calls were simply missed.

This is not cosmetic for Gemini. It attaches a thoughtSignature to every functionCall it emits and rejects the whole request with HTTP 400 when a stored conversation is replayed without it:

Function call is missing a thought_signature in functionCall parts. This is required for tools to work correctly, and missing thought_signature may lead to degraded model performance. Additional data, function call default_api:get_weather, position 2.

The signature survives everywhere else along the path — Bridge/Gemini's ResultConverter reads it into the ToolCall, and its AssistantMessageNormalizer writes it back out as thoughtSignature — so any MessageStoreInterface built on this normalizer breaks tool calling with Gemini as soon as a conversation is persisted and resumed.

The fix mirrors what the class already does for Thinking, in the two places a ToolCall is stored:

• AssistantMessage parts, which already carry a MessageNormalizer-owned envelope around the normalized tool call, so the signature goes next to it;
• ToolCallMessage, where the signature is added as a sibling key on the normalized payload, and only when there is one.

It deliberately does not touch Platform\Contract\Normalizer\Result\ToolCallNormalizer: Contract registers
it by default for outgoing request payloads, so a new key there would leak into OpenAI- and Mistral-style request bodies. MessageNormalizer is persistence-only, which makes it the right place.

The legacy content + toolsCalls denormalization fallback is left alone: data stored in that format predates signatures, so there is never one to restore.

Existing round-trip tests are unaffected, and one of them now also asserts that an unsigned tool call stays unsigned.

[wachterjohannes]

Confirms signature now round-trips through both the ToolCallMessage and parts-based AssistantMessage denormalize paths, matching the existing normalize side. Verified locally, all green.

[wachterjohannes]

Thank you @RomainLvr.