apply_patch turns CRLF files into mixed line endings

[skyzhao1223]

Describe the bug

apply_patch has no CRLF handling. Patch.derive splits the file on \n, so a CRLF file's lines keep their trailing \r. The model supplies LF context lines (it only ever sees LF from read), so exact matching fails and seek falls back to rstrip (trimEnd()), which matches by stripping the \r. The hunk is then spliced back using the model's LF lines, replacing the CRLF line endings only on the touched lines.

Result: a consistently-CRLF file becomes a mixed-ending file after any update.

Repro: derive("f", [{ oldLines: ["foo"], newLines: ["FOO"] }], "foo\r\nbar\r\n") → "FOO\nbar\r\n".

This is the apply_patch counterpart of the edit mixed-line-ending issue (#45880); the edit fix (#45888) did not cover the patch/apply_patch path.

Suggested fix

Detect the file's dominant line ending and preserve per-line endings when splicing the hunk (or normalize the touched region consistently), mirroring the edit tool.

Environment

• opencode version: latest dev

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Tool apply_patch messes up line endings in windows #37090: apply_patch messes up line endings on Windows (CRLF → LF introduced on new/edited lines)

The root cause described there overlaps significantly with this report. It may be worth coordinating or referencing that issue.

[pengzh1]

Taking this — will preserve each line's original ending when splicing hunks in the patch path (LF context from read shouldn't rewrite CRLF lines), with a unit test on the exact derive repro.