fix(tui): decode TUI startup subprocess output as utf-8 on Windows

[teknium1]

Summary

Windows hermes --tui no longer crashes with UnicodeDecodeError: 'charmap' codec can't decode byte 0x8f when npm/node emit bytes outside the active ANSI code page — all TUI launcher subprocess captures now decode as UTF-8 with replacement.

Salvage of #43790 by @helix4u (authorship preserved via cherry-pick), plus one sibling fix.

Changes

• hermes_cli/main.py: encoding="utf-8", errors="replace" on the node bootstrap probe, TUI npm install, dev prebuild, and npm run build captures (contributor)
• hermes_cli/main.py: same fix for the WhatsApp bridge npm install capture — same bug class, audited via subprocess-capture sweep (follow-up)
• tests/hermes_cli/test_tui_npm_install.py: asserts the decode policy on the npm captures

Validation

Check	Result
pytest tests/hermes_cli/test_tui_npm_install.py	27 passed
E2E: subprocess emitting raw 0x8f byte with the new decode args	no exception, replacement char
Contributor's Windows AppData check	startup traceback gone
Sweep of remaining capture_output+text=True sites in main.py	rest are git/systemctl/ps (ASCII output), left alone

Infographic

[github-actions]

🔎 Lint report: fix/tui-utf8-subprocess-decode vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10717 on HEAD, 10717 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 5609 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.