fix(doctor): pin utf-8/replace decoding for captured subprocesses

[Bartok9]

Summary

• hermes doctor crashed with UnicodeDecodeError on non-UTF-8 Windows locales (CP936/GBK).
• Captured subprocess output now decodes deterministically and survives undecodable bytes.

Motivation

Closes #49499.

On Chinese Simplified Windows (default locale CP936/GBK), hermes doctor crashed during the connectivity/diagnostic checks:

UnicodeDecodeError: 'gbk' codec can't decode byte 0xaa in position 1753: illegal multibyte sequence

subprocess.run(..., text=True) decodes the child's output with the system locale codec. When a captured child emits UTF-8 bytes that are invalid under GBK, the decode raises inside subprocess's reader thread and takes down the command that's supposed to be the first troubleshooting step.

Fix

Add a small helper _run_text_subprocess() that pins encoding="utf-8" and errors="replace" (both caller-overridable), and route the two text-capturing doctor probes — the SSH connectivity check and the npm audit check — through it. Undecodable bytes now degrade to the replacement character instead of crashing, exactly as the issue's "Suggested Fix" requested.

The two byte-only captures (docker info, gh auth status) don't decode text and are left unchanged.

Verification

• python3 -m pytest tests/hermes_cli/test_doctor.py — 70 passed

Real behavior proof

• Behavior addressed: a captured subprocess emitting bytes (0xaa 0xff) that are illegal under GBK.
• Before (reproduces hermes doctor crashes with UnicodeDecodeError on Chinese Windows GBK locale #49499) — decoding those bytes with the GBK locale codec:

gbk -> CRASH (reproduces #49499): 'gbk' codec can't decode byte 0xaa in position 2: illegal multibyte sequence

• After — same bytes through _run_text_subprocess(...):

helper -> survives: 'ok\ufffd\ufffd tail'

• Regression test: tests/hermes_cli/test_doctor.py::TestRunTextSubprocess::test_survives_bytes_invalid_under_gbk spawns a child that writes b'ok\xaa\xff tail' and asserts the helper returns cleanly (returncode 0, output preserved) — it would raise UnicodeDecodeError under a GBK locale with the old text=True path.
• What was NOT tested: the live GBK Windows environment itself (no Windows runner locally); the test reproduces the decode mechanism cross-platform by exercising the exact byte pattern.

[alt-glitch]

Duplicate of #49510 — both fix #49499 by pinning encoding="utf-8", errors="replace" on the same two text-mode subprocess sites (SSH probe + npm audit) in hermes_cli/doctor.py. #49510 was opened earlier (the canonical fix); this PR factors the same logic into a _run_text_subprocess() helper, but the behavior change is identical.

[Bartok9]

Thanks @alt-glitch — you're right, this duplicates #49510 (opened earlier by @briandevans), which is the canonical fix for #49499. Same two text-mode subprocess sites, same encoding="utf-8", errors="replace" behavior. Deferring to the earlier PR — closing this in its favor.

@briandevans if it's useful, the only delta here was factoring the two call sites into a shared _run_text_subprocess() helper to avoid the duplicated kwargs; feel free to fold that in or ignore. Either way #49510 should be the one that lands. 👍