webui: add OAI-Compat Harmony tool-call streaming visualization and persistence in chat UI

[ServeurpersoCom]

• Purely visual and diagnostic change, no effect on model context, prompt construction, or inference behavior
• Introduces full support for delta.tool_calls streaming from Harmony-compatible models
• Adds parsing, incremental merging, and live updates of tool-call deltas in ChatService
• Extends chat store, database schema, and message model to persist toolCalls content alongside reasoning traces
• Implements new Svelte components ChatMessageToolCallBlock and ChatMessageToolCallItem for structured display of tool-call payloads
• Adds a fallback raw string mode for malformed or non-JSON tool-call chunks
• Adds 'Show tool call chunks' toggle in chat settings and new config flag showToolCalls
• Updates ApiChatCompletion types to define ToolCall and ToolCallDelta interfaces for typed Harmony compatibility
• Integrates tool-call rendering in ChatMessageAssistant when showToolCalls is enabled

Close #16597

[ServeurpersoCom]

I have to do a little cleaning, the patch was not merged properly on my side. -> draft

[ServeurpersoCom]

This PR is now clean, but it was developed after this one: #16562

[allozaur]

Alright, @ServeurpersoCom, let's move forward with this one after merging #16562 ;) Let me know when you've addressed the merge conflicts and I'll gladly review the code

[ServeurpersoCom]

For the tool call inspector, do you prefer having one spoiler block per tool call, or a single aggregated spoiler wrapping all tool calls in the message?

It's rebased/reworked now. I push --force :)

[ServeurpersoCom]

Feel free to dissect the architecture as deep as you want! Component boundaries, store coupling, service layering, anything that smells non-idiomatic.
Also, if we end up polishing this feature further, I’m thinking it could live in a dedicated module for cleaner boundaries ?

lib/
 └─ toolcalls/
     ├─ toolcall-service.ts
     ├─ toolcall-store.ts
     ├─ ToolCallBlock.svelte
     └─ ToolCallItem.svelte

[ServeurpersoCom]

And we could even imagine the architecture being reusable later : like having a small JavaScript execution module decoupled from the UI, so the model could actually interact with a JS thread it coded itself.
That would also cover, in a more generic way, the proposal from PR #13501 by @samolego but in this case, the model would generate and run its own JS tools. Done properly, it’s no more of a security risk than the HTML/JS preview you get in Hugging Face Chat or Claude!

[ServeurpersoCom]

Includes a very small optimization from the previous PR (scroll listener removal). It landed here intentionally :D