fix(tui): decode slash worker streams as UTF-8

[frizikk]

What does this PR do?

Fixes #63686.

On Windows systems using a CJK locale, subprocess.Popen(..., text=True) defaults to the system code page (for example GBK). _SlashWorker reads UTF-8 output from the slash-worker subprocess without an explicit encoding, so undecodable bytes can raise UnicodeDecodeError in the stderr-draining daemon thread and take down the gateway.

The worker now explicitly decodes stdout/stderr as UTF-8 and replaces malformed bytes, preserving the gateway process while retaining diagnostic output.

Related Issue

Fixes #63686

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• tui_gateway/server.py
  • Set encoding="utf-8" and errors="replace" on the persistent _SlashWorker subprocess.
• tests/test_windows_subprocess_no_window_flags.py
  • Added a regression test that locks the subprocess stream decoding contract.

How to Test

1. The reported failure mechanism was reproduced on Linux by simulating the Windows GBK locale: decoding UTF-8 subprocess bytes containing 0xAA with gbk raised UnicodeDecodeError.
2. Run the focused Windows subprocess contract tests:

scripts/run_tests.sh tests/test_windows_subprocess_no_window_flags.py -q
16 passed

3. Run the gateway server regression suite:

scripts/run_tests.sh tests/test_tui_gateway_server.py -q
322 passed

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate; no PR was found for Windows CJK locale: UnicodeDecodeError in _SlashWorker crashes gateway (text=True defaults to GBK) #63686 or _SlashWorker encoding.
• My PR contains only changes related to this fix/feature
• I've run pytest tests/ -q and all tests pass — focused suites were run; the full suite was not run
• I've added tests for my changes
• I've tested on my platform: CachyOS Linux; Windows-specific behavior was validated by a GBK decoding reproduction and subprocess contract test

Documentation & Housekeeping

• I've updated relevant documentation — N/A; this is an internal subprocess encoding fix
• I've updated cli-config.yaml.example — N/A; no config keys changed
• I've updated CONTRIBUTING.md or AGENTS.md — N/A; architecture/workflow unchanged
• I've considered cross-platform impact; UTF-8 is explicit on all platforms and errors="replace" prevents malformed diagnostics from terminating the reader
• I've updated tool descriptions/schemas — N/A; no tool behavior/schema changed

For New Skills

N/A — this PR does not add a skill.

Screenshots / Logs

Not applicable. The focused tests and gateway regression suite pass; the simulated Windows-locale reproduction produced the reported UnicodeDecodeError before the fix path was applied.

[teknium1]

Thanks for the focused Windows compatibility fix. The current _SlashWorker spawn uses text=True without an explicit codec at tui_gateway/server.py:314-325, while its daemon readers consume both pipe streams at tui_gateway/server.py:329-340. The worker emits JSON-line responses on stdout at tui_gateway/slash_worker.py:169; specifying UTF-8 with replacement handling at the parent pipe boundary is correct and preserves diagnostics.

The only text-mode Popen stream-reader in tui_gateway/ is this _SlashWorker path. The added regression assertion covers the exact Popen contract. No problems found.

Automated hermes-sweeper review.

[teknium1]

Closing as resolved by PR #70850 (merged, commit ead23aa), which hardened the slash-worker Popen (and every other text=True capture site in the desktop/TUI backend) with encoding="utf-8", errors="replace". Credit for the earliest version of this fix goes to @devorun (#52700) and @Sahil-SS9 (#61978, cherry-picked as the base). Thanks for the fix and test.