Read interactive input files as UTF-8

[Mohammed Alkindi (MohammedAlkindi)]

process_requests opens the input file with no encoding, so it follows locale.getpreferredencoding(False). On a Windows box with a cp1252 code page that fails two ways. Measured on CPython 3.13.13, getpreferredencoding = cp1252:

UTF-8 file, Japanese  -> UnicodeDecodeError: 'charmap' codec can't decode byte 0x81
UTF-8 file, "café"    -> 'café au lait'   (no exception, handed to the request handler)

The quiet one is the worse of the two, since that mojibake goes into the model prompt.

The TypeScript twin of this function reads the same files with fs.readFileSync(inputFileName).toString(), which is UTF-8 on every platform, so this also makes the two ports agree rather than picking an encoding arbitrarily.

One behaviour change worth stating: an input file actually encoded as cp1252, which currently reads on Windows, now raises. That converts a silently-wrong path into either correct output or a loud error. All ten tracked input*.txt files are ASCII, so nothing shipped is affected.

The test simulates a non-UTF-8 default rather than reading the host locale, so it exercises the same path on Linux CI. It fails on the unmodified source with the UnicodeDecodeError above.

Same file and function as #248.

[robgruen]

Maybe add a café regression test to explicitly cover silent corruption.

[Mohammed Alkindi (MohammedAlkindi)]

Added in 3e61b99: a new test writes a café line as UTF-8 under a cp1252 default encoding and asserts it reads back unchanged. cp1252 decodes those bytes without raising, so that is the case where the old read corrupted input silently.