Edit silently corrupts non-UTF-8 files (ISO-8859-1 bytes replaced with U+FFFD) #49600

Summary

The edit tool silently destroys non-UTF-8 bytes. Editing an ASCII-only region of a file that contains ISO-8859-1 bytes elsewhere rewrites those bytes as U+FFFD (EF BF BD), reports success, and leaves phantom diff hunks. This is data loss with no warning.

Minimal reproduction

printf 'const x = 1;\n// caf\xe9 note\n' > sample.txt  # 0xE9 = e-acute in ISO-8859-1
# then use the edit tool: oldString "const x = 1;" -> newString "const x = 2;"

Before (xxd): ... 63 61 66 e9 20 ...
After: ... 63 61 66 ef bf bd 20 ... — the untouched 0xE9 byte became U+FFFD. The tool reported success.

Real-world hit: a 1140-line ISO-8859-1 Java file where I made one logical change came back with ~10 unrelated comment lines rewritten (0xF3 -> EF BF BD). Caught only via git diff review; without that check it would have been committed corrupted.

Expected

Either decode with { fatal: true } and refuse with a "file is not valid UTF-8" error, leaving the file untouched (matching the read tool's MalformedUtf8Error behavior), or preserve the original encoding on write. Never silently replace bytes and report success.

Environment

• opencode 1.18.30, linux
• files: ISO-8859-1, both CRLF (real case) and LF (minimal repro)

Related

Same defect class as #28521 (Windows-1252), #7933, #27832, #3342 — all currently closed by the stale bot with no fix landed. Open fix PR #26406 (chardet + iconv-lite) would address this; this report adds a fresh byte-level repro against the current version to validate against.