pushToolWriteResult serialises provider fields the previous save overwrote, so a tool result can describe the wrong file #2353

Measured on src/core/webview/ClineProvider.ts at the head of PR #1931, pinned nodejs 22.23.4.

saveChanges both writes this.newProblemsMessage and this.userEdits (around :520-528) and returns them (:523 and :530). WriteToFileTool discards that return value at :488, awaits trackFileContext (:497), then calls pushToolWriteResult(task, cwd, isNewFile) (:502), which re-reads the provider fields this.relPath (:543, :552, :578), this.userEdits (:548, :564, :583-584) and this.newProblemsMessage (:587-588). The signature at :542 carries no save-scoped value.

A probe added to the provider spec (run, then reverted; spec blob restored to 4dc3cd590ff4): after a save of a.ts the discarded result carries that patch; after a later save of b.ts the only available serialisation reports "path": "b.ts" with B patch and nothing from A. pushToolWriteResult appears 0 times in the 2,851 lines of that spec, so nothing pins the behaviour.

The fix is cross-cutting: threading a save-scoped result plus relPath into pushToolWriteResult touches seven production callers (WriteToFileTool:502, ApplyDiffTool:253, ApplyPatchTool:226 and :446, EditFileTool:462, EditTool:229, SearchReplaceTool:225) and five test doubles, so it belongs in its own change rather than the tail of one PR last push. Filed from a review thread on #1931 (root comment 4504426416, answered, thread left open by agreement).