fix(tui_gateway): set utf-8 encoding for subprocess pipes on Windows

[escalate007]

Problem

On Chinese Windows systems (GBK system encoding), subprocess.Popen with text=True defaults to the system locale for pipe decoding. When the Hermes backend writes UTF-8 bytes to stderr, the _drain_stderr thread crashes with UnicodeDecodeError: 'gbk' codec can't decode byte. This makes the desktop/TUI backend unresponsive — the user clicks send after uploading a file and nothing happens.

Root cause

tui_gateway/server.py line 339: text=True without an explicit encoding=. Python uses the locale encoding (GBK on zh-CN Windows), but the backend process outputs UTF-8.

Fix

Add encoding='utf-8' to the Popen call, after text=True. This is a one-line change, safe on all platforms — Python ignores unknown encoding parameters on non-Windows systems where UTF-8 is already the default.

Related logs

[gateway-crash] thread Thread-14 (_drain_stderr) raised UnicodeDecodeError:
'gbk' codec can't decode byte 0xa0 in position 7: illegal multibyte sequence

And also Python's internal _readerthread in subprocess.py: UnicodeDecodeError: 'gbk' codec can't decode byte 0x94 in position 140: illegal multibyte sequence

[alt-glitch]

This was generated by AI during triage.

Related to open #52700 and report #52649. This patch fixes the slash-worker Popen only; #52700 also covers git subprocesses and uses errors="replace", so the narrower scope needs a maintainer consolidation choice.

[teknium1]

Closing as superseded by PR #70850 (merged), which covers this Popen site plus every other text=True capture in the desktop backend. Note the merged version also passes errors="replace" alongside encoding="utf-8" — without it, a child emitting genuinely invalid UTF-8 would still raise in the drain thread. Credit to @Sahil-SS9's earlier #61978 for the server.py hardening that was cherry-picked as the base; thanks for the report and fix regardless.