fix: use explicit utf-8 encoding in compress/validate file I/O

[Abhishaex]

On Windows, Python's read_text/write_text default to the system codepage (cp1252), which crashes or silently truncates when content contains non-ASCII characters (emojis, CJK, wenyan output).

Fixes #652, fixes #655.

[francojeferson]

Heads up — this misses detect.py. #686's body lists the extensionless-file content sniff as a call site needing the fix, but the diff here only covers compress.py and validate.py.

         try:
-            text = filepath.read_text(errors="ignore")
+            text = filepath.read_text(encoding="utf-8", errors="ignore")

It only classifies, so it can't corrupt a file. But on a non-UTF-8 locale it can misdecode prose, trip a CODE_PATTERNS match, and silently skip a file the user explicitly asked to compress.

Separately, encoding= on its own only fixes half of the Windows text-mode default. write_text still translates \n to \r\n, so every processed file comes back with its line endings rewritten — measured a 67-line LF file returning 67 bytes larger. Filed that as #762 with a patch in #763.

#763 contains this PR's change verbatim, because both touch identical call sites and splitting them would just conflict. Not trying to step on this one — happy to rebase #763 down to newline-only if this merges first.