fix: Fix Windows encoding and subprocess output handling in code.py

[iawe-UON]

Description

This PR addresses two runtime errors in code.py that can appear when tools read files or execute shell commands on Windows.

Changes Proposed

• Use explicit UTF-8 encoding for file reads and writes in run_read, run_write, and run_edit.
• Add decoding fallback such as errors="replace" when reading files to avoid crashes on non-GBK bytes.
• Make subprocess output concatenation null-safe in run_bash by treating missing stdout or stderr as empty strings.
• Optionally set encoding="utf-8" and errors="replace" in subprocess.run.

Problem

On Windows, Path.read_text() defaults to the system locale encoding, often GBK in Chinese environments. Reading UTF-8 files can raise:

UnicodeDecodeError: 'gbk' codec can't decode byte ...

Also, run_bash concatenates subprocess output directly:

r.stdout + r.stderr

If either value is None, Python raises:

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Expected Result

File tools should handle UTF-8 content consistently across platforms, and shell command output handling should not fail when either stdout or stderr is missing.

[vercel]

Someone is attempting to deploy a commit to the crazyboym's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Gui-Yue]

@iawe-UON
Thanks for the fix. The direction looks good, especially making file IO explicit UTF-8 for Windows.
One concern: using errors="replace" in run_edit may silently rewrite non-UTF-8 bytes as replacement characters when the file is saved back. I think errors="replace" is fine for run_read, but for run_edit it would be safer to read/write with strict UTF-8 so we fail instead of corrupting the file.
Could you adjust run_edit to use encoding="utf-8" without errors="replace"? The subprocess/output handling change looks fine.