Streamfold for message-accumulator tool arguments

Proposal

Evaluate using the existing streamfold/assistant-ui adapter automatically inside AssistantMessageAccumulator, with one retained parser per tool-call part. This is separate from #7369 and draft #7371, which concern ToolCallReader.

The candidate preserves the existing parser for structural updates and compatibility fallback, and uses immutable Streamfold snapshots for string appends. It preserves field metadata, malformed-input behavior, resumed messages, independent calls, and cleanup. Engine loading is deferred; text-only streams do not request it.

Evidence and decision

The candidate passes the assistant-stream suite with live Redis in both supported client lanes, tested with Streamfold 0.1.6 and 0.1.7, plus downstream core/data-stream/performance-contract tests and Chromium/Firefox/WebKit fallback/cancellation checks. A paired local public-pipeline experiment improves 50 KB strings by about 9x, while the weather fixture regresses from 0.130 to 0.224 ms and a nested-item fixture from 6.580 to 8.602 ms. A minimal consumer adds 895 gzip bytes initially and 27,838 deferred gzip bytes. These are local measurements, not model latency claims.

Is this dependency and hybrid parsing direction desirable for the accumulator? The implementation will be a draft, with full measurements and limitations. Default adoption should remain under review until small/nested-input regressions, startup/download cost, React Native behavior, and the final CI results are addressed.