fix(gateway-windows): handle non-ASCII paths and uv pythonw shim on CJK Windows

[Shura0307]

Problem

Two bugs affect Chinese/Japanese/Korean Windows users whose home directory contains non-ASCII characters (e.g. C:\Users\银\...):

1. .cmd file corruption — _build_gateway_cmd_script() writes raw UTF-8 CJK characters into the generated .cmd file. cmd.exe on these Windows editions interprets the file using the system ANSI/OEM code page (e.g. GBK for zh-CN), which garbles the set and cd commands and silently breaks the Scheduled Task startup.

2. Visible console window at startup — _build_gateway_cmd_script() uses _derive_venv_pythonw(python_path) which returns the venv's pythonw.exe. On uv-created venvs, venv\Scripts\pythonw.exe is a shim that spawns the base interpreter python.exe (a console-mode app), opening a visible Windows Terminal window.

3. start() gives up too early — When schtasks /Run returns exit code 0 but the gateway process does not appear within 6 seconds (common on slower machines), start() reports failure and returns without starting the gateway.

Fix

_cmd_safe_path() — new helper that replaces APPDATA/ LOCALAPPDATA prefixed paths with their environment-variable form (%APPDATA%, %LOCALAPPDATA%), keeping the generated .cmd files pure ASCII regardless of the user's home directory encoding.

uv-aware pythonw — _build_gateway_cmd_script() now calls _resolve_detached_python() (the same function _spawn_detached() already uses) to get the true base pythonw.exe from the uv cache, and passes the venv site-packages via PYTHONPATH. No more window popping up.

Graceful start() fallback — When schtasks /Run succeeds but no process appears within the 6-second window, start() now falls back to _spawn_detached() instead of silently giving up.

Testing

Tested on Windows 11 Home zh-CN with username 银 (a CJK character):

• hermes gateway start -> gateway starts silently, no console window
• hermes gateway restart -> clean stop + silent start
• Generated .cmd file is pure ASCII (zero CJK characters)
• Scheduled Task logon startup works without corruption

[teknium1]

Thanks for documenting the localized Windows and uv-launcher failure modes. This is an automated hermes-sweeper review; current main now provides the requested behavior through a later, different launcher design.

• hermes_cli/gateway_windows.py:659-663 creates Scheduled Tasks for wscript.exe and the generated .vbs launcher, rather than executing the raw .cmd wrapper; the Startup fallback follows the same VBS route (hermes_cli/gateway_windows.py:549-556).
• The uv workaround is already in the shared launch path: _build_gateway_cmd_script() calls _resolve_detached_python() (hermes_cli/gateway_windows.py:404), which selects base pythonw.exe and supplies venv site-packages for uv environments (hermes_cli/gateway_windows.py:734-756). Regression coverage is present at tests/hermes_cli/test_gateway_windows.py:213-245.
• start() now directly calls _spawn_detached() (hermes_cli/gateway_windows.py:1460-1490), so it no longer relies on schtasks /Run or its readiness wait. This was introduced by e7d2f0b93ca29b2cd95d6623fe8af7646173a75b; the Scheduled Task VBS migration shipped in 433db17c0a8d5581b4fb38289539fc1ee5cc7696.

The timeline’s related PR #41028 reports the same uv shim behavior; main now contains the corresponding production handling and test coverage. Closing as implemented on main.