edit: oldString never matches on files with mixed line endings (read strips \r, edit converts whole oldString to CRLF)

Description

On a file with mixed line endings (e.g. one commit from a Windows colleague introduced a single CRLF line into an otherwise-LF file), the edit tool can never match oldString, even when the model faithfully reproduces exactly what the read tool showed it.

Two behaviors combine:

1. read strips a trailing \r from each line (packages/core/src/tool/read-filesystem.ts line-splitting: current.endsWith("\r") ? current.slice(0, -1) : current), so the model always sees pure LF content.
2. edit picks the file ending with detectLineEnding — which returns "\r\n" if \r\n appears anywhere in the file — and then convertToLineEnding rewrites every \n in the model's oldString to \r\n (packages/core/src/tool/edit.ts:42-45 and the apply path).

If the region the model targets happens to use LF endings, the converted oldString no longer exists in the file → misleading "Could not find oldString. It must match exactly..." failure. The model cannot even know the file is mixed, because read hid the \r.

A secondary effect: once a match does succeed in the CRLF region, newString is written with CRLF into what may be an LF area, further mixing the file.

Reproduction

printf 'alpha\nbeta\r\ngamma\n' > /tmp/mixed.txt

1. read /tmp/mixed.txt → the model sees alpha\nbeta\ngamma\n (all LF)
2. edit with oldString: "alpha\nbeta" → fails with "Could not find oldString"

Simulating edit's exact logic (detectLineEnding + convertToLineEnding):

file bytes:                "alpha\nbeta\r\ngamma\n"
detectLineEnding(file) =   "\r\n"        <- one CRLF anywhere is enough
oldString sent by model:   "alpha\nbeta"
oldString after convert:   "alpha\r\nbeta"
indexOf result:            -1             <- match fails

Expected

Edit on mixed-ending files should succeed for regions the model saw via read, e.g. by matching per-line (normalizing line endings for comparison while preserving the file's original per-line endings in the replacement), or at least by only treating the file as CRLF when it is consistently CRLF.

Happy to take this on with the maintainer-preferred approach.