fix(streaming): dedupe content, recover reasoning, unique tool_call IDs in deferred flush

[mudler]

When tool calls are discovered only during final parsing (after the streaming token callback returns), processTools' default switch branch used to emit the full accumulated content alongside the tool_call args chunk. Clients that accumulate delta.content per the OpenAI streaming contract end up showing every narration line twice. Three related bugs in the same flush path:

1. Content duplication: the args chunk carried Content:textContentToReturn even though the text had already been streamed token-by-token via the token callback, so delta.content was both the running total and bundled with tool_calls in one delta (two spec violations).
2. Reasoning drop: when the C++ autoparser surfaces reasoning only as a final aggregate (no incremental tokens), the callback never emits it and the flush branch didn't either, silently losing it.
3. tool_call ID collision: empty ss.ID fell back to the request id, so multiple empty-ID calls in the same turn all shared the same id, breaking tool_result matching by tool_call_id.

Extracted the block into buildDeferredToolCallChunks (pure function, unit-testable) and added 19 Ginkgo specs covering streamed vs. not-streamed content/reasoning, single vs. multi call, and incremental-vs-deferred emission. Every case asserts the invariant that no delta carries both non-empty Content/Reasoning and non-empty ToolCalls.

Fix summary:

• emit reasoning in its own leading chunk when !reasoningAlreadyStreamed
• emit role+content in their own chunks when !contentAlreadyStreamed
• drop Content from the tool_call args chunk
• fallback to fmt.Sprintf("%s-%d", id, i) for empty ss.ID so calls stay uniquely addressable

Reproduced live against qwen3.6-35b-a3b-apex served by LocalAI with the C++ autoparser; the full-content replay chunk that preceded each tool_calls block is gone after the fix.