[bug] str_replace_editor: insert writes LF line endings into a CRLF file (mixed EOL)

[kharkilirov1]

Affected: master @ 0.1.0-rc.7 — packages/fs/tool-str-replace-editor/src/index.ts, insertInFile (before.split('\n') … .join('\n'))

Symptom

insert writes every separator it creates as a bare \n, so inserting into a CRLF file produces a mixed-EOL file: the inserted lines end with LF while the untouched lines keep CRLF.

Reproduction

1. Create note.txt with content one\r\ntwo\r\n.
2. Run insert with insert_line: 2, new_str: "three".

Expected:

one\r\ntwo\r\nthree\r\n

Actual:

one\r\ntwo\r\nthree\n

The untouched lines keep CRLF only because their \r rides along inside the split content; a multi-line new_str inserts an entire LF-only block into a CRLF file.

Root cause

The file is split on '\n' and rejoined with '\n', so every separator the splice creates is LF.

Fix

Splice the inserted block at the insertion point's own byte offset instead of splitting and rejoining the whole file: separators outside the insertion point keep their exact bytes, and the block takes the line ending found at the insertion point (the preceding line's terminator; the file's first/last separator for line 0 or an append past the last line). LF files are byte-identical to the previous behavior.

A tested patch (homogeneous CRLF file; mixed-EOL a\nb\r\nc\n changing only at the insertion point, including a second insert landing on the CRLF line) is available in my fork:

• commit: kharkilirov1@ec13f84
• full fix batch: master...kharkilirov1:deepseek-harness:fix/windows-snapshot-infra-and-tool-robustness

Happy to adapt it to the maintainers' preferred format.