fix: repair malformed JSON in edit_file tool call arguments

[trungutt]

Summary

LLMs sometimes generate broken JSON when calling edit_file. This happens because the text being edited (YAML files, Dockerfiles, shell scripts) contains braces, brackets, and escape characters that throw off the model's nesting depth tracking. The result is structurally invalid JSON that fails to parse, wasting a turn and forcing the model to retry.

I looked at all edit_file calls across several sessions and found that 11 out of 53 calls (21%) had malformed arguments. All of them were close to valid — typically just one extra } or ] in the wrong place.

The existing UnmarshalJSON fix for double-serialized edits (#2144) doesn't help here because Go's json.Unmarshal scanner rejects the structurally invalid JSON before any custom unmarshaler runs.

What this PR does

Adds tryRepairEditFileJSON which, on a json.SyntaxError, looks at the character at the error offset and removes it if it's a known garbage pattern. It loops up to 3 times to handle multiple issues in the same payload. The observed failure patterns from real sessions:

Pattern	Count	Example	Repair
Extra }	8	"}}]} instead of "}]}	Remove the extra }
Extra ]	2	"}]]} instead of "}]}	Remove the extra ]
Stray \n between tokens	1	"}\n]}	Remove both \ and n
Stray \ before "	1	{\"key" instead of {"key"	Remove the \

Since the repair needs to happen before json.Unmarshal, the edit_file handler now uses a custom editFileHandler() instead of the generic tools.NewHandler, calling the new exported ParseEditFileArgs function directly. All other call sites (ACP filesystem handler, TUI rendering) are updated to use ParseEditFileArgs too.

What it doesn't do

• No generic JSON repair for all tools — this is scoped to edit_file only, where the problem is most acute due to large text payloads
• No changes to the streaming/accumulation path
• Unrepairable garbage (e.g. {totally broken <<<>>>) still fails with a clear error