fix(core): preserve CRLF endings when splicing patch hunks

[pengzh1]

Issue for this PR

Closes #45926

Type of change

• Bug fix

What does this PR do?

Patch.derive split the original on \n, so a CRLF file's lines kept trailing \r while the model's new lines are LF-only (read never shows \r). Splicing the hunk replaced the touched CRLF lines with LF lines, turning a consistently-CRLF file into mixed endings. derive now checks the splice point: when the replaced region (or, for pure insertions, the adjacent line) is CRLF, the inserted lines carry \r too. LF files and mixed files keep their previous behavior.

How did you verify your code works?

Added three unit tests in packages/core/test/patch.test.ts, including the exact repro from the issue (derive("f", [{oldLines:["foo"], newLines:["FOO"]}], "foo\r\nbar\r\n") now yields "FOO\r\nbar\r\n"); they fail on unfixed dev. Existing patch.test.ts + tool-apply-patch.test.ts (18 tests) green, tsgo --noEmit clean.

Screenshots / recordings

Tool behavior fix, no UI.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

• fix(core): match LF regions of mixed-ending files in edit #45888 - fix(core): match LF regions of mixed-ending files in edit
  • fix(core): match LF regions of mixed-ending files in edit #45888
  • This PR also deals with handling line endings in mixed-ending files within the core package, which is closely related to the CRLF preservation logic in PR fix(core): preserve CRLF endings when splicing patch hunks #45931.

The other results (#4604 and #20217) appear to be older, related PRs about CRLF handling but are not current duplicates of this PR.

[pengzh1]

Related but distinct: #45888 fixes the edit tool's matching in mixed-ending files, this one fixes apply_patch's splice (Patch.derive) writing LF lines over CRLF regions — different tool, different code path (packages/core/src/patch.ts), and #45926 notes the edit fix doesn't cover the patch path.

[pengzh1]

Closing this for now — I want to focus on a time-sensitive upstream fix. The branch stays available; I may revisit if the underlying CRLF handling changes.