fix(tools): write_file rewrites CRLF files and drops UTF-8 BOM

[PierrunoYT]

Version / branch / commit

Audited on main at 903e3d13 (2026-08-23).

Problem

read_file normalizes CRLF to LF before returning content. When the model sends that content back through write_file, the tool writes it verbatim without preserving the existing file's line-ending convention or UTF-8 BOM. A small logical change can therefore rewrite every line and remove an encoding marker required by some Windows toolchains.

Reproduction

1. Create a CRLF PowerShell, .resx, or project file; optionally prefix it with UTF-8 BOM bytes EF BB BF.
2. Read it through read_file.
3. Make a small change and write the complete content with write_file.
4. Inspect the bytes or git diff.

Expected behavior

write_file preserves an existing file's CRLF convention and BOM unless the caller explicitly changes them.

Actual behavior

The file is rewritten with LF and the BOM is removed, producing whole-file diff churn and potentially changing how downstream Windows tools decode non-ASCII text.

Relevant code

• internal/tools/write_file.go:97-110
• internal/tools/line_reader.go:40-42
• internal/tools/edit_file.go:92-102 already preserves CRLF for the sibling edit path

Suggested fix

Inspect priorContent for a BOM and dominant line-ending convention, translate the outgoing content consistently, and preserve the original BOM. Add byte-level regression tests for CRLF, LF, BOM+CRLF, and new-file behavior.

[PierrunoYT]

I'm working on this.