FIX: Handle non-UTF-8 output gracefully in run_subprocess

[ishaaaan17]

reference issue (if any)

none

what does this implement/fix?

in mne.utils.run_subprocess, the stdout and stderr are decoded using decode("utf-8"). when some external command gives non-utf-8 bytes, it raises UnicodeDecodeError and the function crashes.

in this pr i have added errors="replace" to both out.decode("utf-8") and err.decode("utf-8"). i have also added test_run_subprocess_non_utf8 to check that the non-utf-8 bytes on stdout and stderr are handled properly without raising any error.

additional information

i wrote the fix myself, and gemini helped me to draft the initial test. after that i reviewed it, formatted it and tested everything locally.

[scott-huberty]

@ishaaaan17 I'm curious if there was a practical motivation for this fix? Like did you hit this error when using MNE-Python?

[ishaaaan17]

hi @scott-huberty,

to be honest with you, i did not face this in any normal MNE analysis pipeline. i noticed it while going through the error handling paths in run_subprocess.

the main reason was the external binaries on different platforms (like FreeSurfer or OpenMEEG tools called through bem.py / surface.py / forward.py). on Windows or localized systems, these subprocesses can sometimes give stdout/stderr in the system code page (for example Windows-1252, or non-utf-8 characters in localized error messages or paths). when strict utf-8 decoding fails with UnicodeDecodeError, it stops before the actual process output or exit code can be logged, so we cannot see what the tool actually did.

adding errors="replace" looked like a simple and safe way to make sure run_subprocess always returns the output without crashing on decoding, and it has no extra cost.

but if you feel it is not needed or too defensive in practice, i understand, and i am happy to close it.