fix(core): preserve mixed line endings in edit tool - #53166

Fixes #53149
Fixes #53151
Refs #45927

Problem

The edit tool picked one line ending for the whole file: source.includes("\r\n") ? "\r\n" : "\n". If a file contained a single CRLF, every \n in both oldString and newString was rewritten to CRLF. In mixed-ending files this:

• wrote CRLF into regions that used LF (one CRLF in the file became two after an edit), and
• made multi-line oldString values fail with the misleading "must match exactly, including whitespace and indentation" error.

The read tool strips \r, so the model never sees CRLF and had no way to work around it.

Fix

• Matching (exact, then Unicode-normalized, then trailing-whitespace) runs against an LF view of the source, which is the same text the read tool shows. Match offsets are mapped back to source offsets, so untouched bytes keep their original endings.
• Inside a match, replacement lines are aligned with the matched lines (longest common subsequence). A line that is kept or changed in place reuses the ending of its source line, so unchanged context keeps its bytes even in a mixed-ending file. Only added lines take the dominant ending of the matched region, or the file's dominant ending for a single-line match or a tie.
• If oldString and newString differ only in \r, the edit is treated as a line-ending change and applied to the exact bytes. Explicit CRLF↔LF conversion still works.
• An edit that would leave the file unchanged now fails instead of reporting success (edit reports success for a CRLF-only line-ending change that does nothing #45927). The error says how to change line endings explicitly.
• The tool description now says to write line breaks as \n, that existing endings are preserved, how to change endings explicitly, and the lenient fallback tiers that were previously undocumented.

Testing

• Unit tests cover the byte-level repro from edit tool silently rewrites line endings; tool description contradicts implementation #53149 (head\r\nAAA OLD BBB\ntail\n), a mostly-CRLF file whose oldString crosses a lone LF line, unchanged context inside a mixed-ending match, explicit CRLF→LF conversion, and the no-op failure.
• bun test test/tool-edit.test.ts in packages/core: 20 pass.
• bun run check: passes.

Eval results

The runs come from two dumber evals: line-endings and line-endings-realistic. 20 models (DeepSeek, Grok, Muse, Gemini, GLM, MiniMax, Claude, Kimi, Qwen; GPT is left out because it gets patch instead of edit) × cases × 3 repetitions. Trials only get read, glob, grep and edit, so every byte on disk went through the edit tool. Baseline is 0bef0ea (v2), v1 is 64eb0f6 (this PR's first commit), v2 is d38a53b (this PR's current head). The variants ran at the same time. The baseline and v1 were each run twice to measure noise.

line-endings-realistic: multi-file feature work in a mixed C#/TS/Python/Rust repo (360 trials per run)

The repo has CRLF, LF and mixed-ending files. No prompt mentions line endings. Pass = every requested change is present and no line ending was damaged.

Pass rate per case (out of 60):

v1 still damaged line endings: unchanged context inside a multi-line match took the region's dominant ending. v2's per-line alignment removes all of it. The remaining v2 failures are missing requirements (model mistakes) plus one Gemini MALFORMED_FUNCTION_CALL, not line endings. Fewer failed edits also mean fewer retries, which is where the drops in time (about −20%), tokens (about −28%) and cost (about −16%) come from.

line-endings: single-file edits with known bytes (780 trials per run)

11 of the 13 cases are at or near 100% in every variant.

• v1 regressed explicit conversion. Because every \n was normalized, crlf-convert-to-lf could no longer be done with edit, and the tool reported success on a no-op. v2 fixes both. The 9 remaining "unchanged" trials are models that changed the file and then reverted it themselves; the tool now rejects true no-ops.
• Known gap: crlf-convert-to-lf with only edit still passes about half the time, and about a third of trials hit the 300s timeout. Many models (Claude included) write \r as a literal backslash escape instead of a real carriage return, so their oldString never matches. With a shell available this case is trivial.

Full tool set (shell, write, subagents, …)

Same evals with OpenCode's full tool set, baseline 0bef0ea vs v2 d38a53b, run at the same time. The LINE_ENDINGS_TOOLS=all switch and the raw runs are in anomalyco/evals#15.

Realistic pass rate per case (out of 60): add-delete 5 → 55, add-discount 4 → 56, category-two-turns 2 → 52, move-item-value 44 → 60, rename-sku 11 → 47, seed-and-docs 57 → 60.

None of the 17 damaged v2 realistic trials was damaged by edit:

• 12 used write to rewrite a whole CRLF file with LF (DeepSeek V4 Pro accounts for 11 of them, MiniMax M3 for 1). The same trials are damaged on the baseline too.
• 5 rewrote a file with a Python one-liner through shell (text-mode read/write turns CRLF into LF).
• 2 are Claude Opus deliberately normalizing a mixed-ending .cs file to CRLF with perl, as .gitattributes asks. The scorer counts that as damage, but it is a reasonable choice.

The realistic time difference comes from provider stalls that hit the 600s timeout: MiniMax M3 and Gemini 3.8 Flash account for 9 timeouts vs 7 on the baseline, with idle sessions and almost no edits. Median trial time is 52s vs 50s, and tokens and cost are flat.

Not covered yet

• write does not preserve line endings when it overwrites an existing file. It is now the main remaining source of damage with the full tool set. A follow-up could keep the overwritten file's ending.
• patch (used for GPT models) does not touch line endings and is not covered by these evals.
• With only edit, explicit CRLF→LF conversion still fails about half the time because models write \r as a literal escape.

Added by the opencode bot (AI-generated).

Fixes #45927
Fixes #45880

Related: #54605, #45926