Multi-round tool call loops lose round boundaries when stored in DatabaseConversationStore

[nikitaa01]

When an agent executes multiple rounds of tool calls in a single conversation turn, all tool calls and results are stored as flat lists in the database. When the conversation history is reconstructed on the next user message, all rounds are collapsed into a single AssistantMessage + ToolResultMessage pair, losing the original round-by-round sequence.

Providers like Anthropic require the interleaved structure to be preserved:

AssistantMessage [tool_call round 1]
ToolResultMessage [result round 1]
AssistantMessage [tool_call round 2]
ToolResultMessage [result round 2]

Sending the flattened version causes the provider to reject the history on the next user message.

Expected behavior:
The round-by-round sequence is preserved when storing and reconstructing conversation history.

Affected:
All providers that require interleaved tool call/result sequences (Anthropic, Groq).

[CodeWrap]

Ran into the same thing in-memory — #392 adds a contentBlocks property on AssistantMessage that the mapper uses verbatim, so the step order survives. Left the store alone there (#380 covers that side). If rehydrate() filled contentBlocks instead of rebuilding from text + toolCalls, it'd pick up the ordering for free.