fix(streaming): aggregate OpenAI tool-call delta fragments

[yuga-hashimoto]

Priority 2 — Local agent capabilities

Summary

OpenAI-compatible SSE streams emit tool calls as fragments:

1. {id:"call_1", name:"get_weather", arguments:""}
2. {id:"",       name:"",            arguments:"{\"lo"}
3. {id:"",       name:"",            arguments:"cation\":\"Tokyo\"}"}

ChatViewModel.sendMessage and OpenClawProvider.send both appended each delta to a toolCalls list verbatim, producing three broken ToolCallRequests per call:

• one with the real id but empty arguments
• two with empty ids and partial JSON

The dispatcher then ran the first with empty args (tool fell back to defaults or errored) and the later two as "Unknown tool" — a silent failure where the LLM thought the tool succeeded.

Fix

New StreamingToolCallAggregator glues fragments back together. Heuristic:

• A delta with a non-empty id starts a new call (committing the pending one).
• A delta with an empty id appends its name/arguments fragment to the pending call.

Wired into:

• ChatViewModel.sendMessage streaming consumer.
• OpenClawProvider.send (the non-streaming path that still consumes per-event WS messages).

Scope & limitations

• Sequential tool streaming (OpenAI default) works.
• True multi-tool interleaved streaming would need explicit index keys. Documented as a future extension.

Test plan

• New StreamingToolCallAggregatorTest covers: complete single delta, fragment sequence re-assembly, multi-call id boundaries, name-fragment append, orphaned pre-pending fragment, empty chunk no-op, empty aggregator.
• ./gradlew :app:testStandardDebugUnitTest — green
• ./gradlew :app:assembleStandardDebug — green