fix: normalize CRLF line endings in edit tool parameters

[Br1an67]

TLDR

Fixes the Edit tool failing on multi-line edits when old_string contains CRLF (\r\n) line endings but the file content has been normalized to LF (\n). This is a one-line root cause fix plus a regression test.

Dive Deeper

The Edit tool already normalizes file content from CRLF to LF on read (edit.ts:163):

currentContent = fileInfo.content.replace(/\r\n/g, '\n\);

However, the old_string and new_string parameters were not normalized, so when an LLM or Windows IDE provides old_string with CRLF line endings, indexOf() fails to find a match against the LF-normalized content. This is especially common with UTF-8 BOM + CRLF projects on Windows (as reported in #2257).

The fix adds matching CRLF→LF normalization for old_string and new_string before the matching logic runs:

finalOldString = finalOldString.replace(/\r\n/g, '\n\);
finalNewString = finalNewString.replace(/\r\n/g, '\n\);

Reviewer Test Plan

1. Create a file with CRLF line endings on Windows (or printf "line1\r\nline2\r\nline3" > test.txt)
2. Use the Edit tool with a multi-line old_string containing CRLF
3. Verify the edit succeeds (previously would fail with "no match found")

Testing Matrix

	🍏	🪟	🐧
npm run	❓	❓	❓
npx	❓	❓	❓

Linked issues / bugs

Fixes #2257

[tanzhenxin]

This issue cannot be reproduced on Windows system, with utf-8 bom + CRLF newlines. I suspect the real edit problem is related to #1922 , which involved mixed Chinese/English character.