fix: show streaming progress for large tool inputs instead of stuck Preparing write

[guazi04]

Issue for this PR

Closes #11112

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When AI writes large files (100KB+), the TUI shows a static "Preparing write..." message for minutes while waiting for the complete JSON argument to arrive. This is caused by HTTP proxies buffering the SSE stream (the JSON-escaped tool content has no real newlines to trigger proxy flushes). The tool-input-delta events were completely ignored in processor.ts (no-op break), so the UI had no way to show progress.

This PR processes tool-input-delta events to provide streaming progress:

processor.ts: Accumulates delta bytes per tool call, extracts filePath early via regex on partial JSON (capped at 8KB scan buffer), and throttle-updates the part state (every 500ms or 16KB). JSON-escaped paths are properly decoded. Accumulators are cleaned up on both tool-input-end and tool-call events to prevent leaks on abnormal termination.

write.ts: Reordered schema to put filePath before content, nudging models to emit it first for earlier extraction.

TUI: Write/Edit/ApplyPatch components now show dynamic progress — e.g. "Preparing write… (64KB)" or "Write src/foo.ts (receiving… 128KB)" instead of a static message.

message-v2.ts: Added optional received field to ToolStatePending for byte count tracking.

The fix is best-effort: if regex extraction fails, it degrades to showing byte count only; if no deltas arrive at all, it falls back to the original static message. Tool execution is unchanged — still waits for complete JSON via tool-call event.

Note: PR #10925 also handles tool-input-delta by populating state.raw with full accumulated args. Our approach differs — we avoid storing the large raw string and instead extract only small metadata (filePath + byte count) for UI progress. These could potentially be combined.

How did you verify your code works?

• TypeScript compiles with zero errors (both tsc --noEmit and CI typecheck pass)
• All CI checks pass (12/12): unit tests (Linux + Windows), e2e tests, typecheck, nix-eval
• Code reviewed for correctness: regex handles JSON-escaped paths, throttling prevents DB spam, memory is bounded
• Graceful degradation verified: missing filePath shows byte count only, no deltas = original behavior

Screenshots / recordings

N/A — this is a streaming progress indicator that only manifests with real LLM tool calls behind proxied connections. The TUI change is purely text-based (no layout changes).

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• feat: stream partial tool arguments #10925 - feat: stream partial tool arguments

This PR appears related because it also deals with streaming tool arguments, which is the core mechanism being enhanced in PR #16024 to provide real-time progress feedback during large tool input transmission.

No duplicate PRs were found that address the same issue of showing streaming progress for large tool inputs.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[guazi04]

Thanks for flagging #10925! The two PRs touch the same tool-input-delta handler but take different approaches:

• feat: stream partial tool arguments #10925 appends every delta to state.raw and calls updatePart on each one — stores the full accumulated JSON string (can be 100KB+) in DB
• This PR skips storing raw content entirely — only extracts small metadata (filePath via regex + byte count), throttles updates to every 500ms/16KB, and adds TUI progress display

They could potentially be combined, but this PR is specifically focused on the UX side of #11112 (showing progress instead of a stuck "Preparing write..." message).