fix(gateway): guard faulthandler.enable() against sys.stderr=None on Windows

[brantleyjill]

Problem

faulthandler.enable() crashes with RuntimeError: sys.stderr is None when the gateway is spawned as a subprocess without a TTY on Windows. This happens because faulthandler defaults to writing to sys.stderr, which is None in that context.

This breaks two scenarios:

• hermes gateway start — spawns the gateway as a child process, crashes immediately with exit code 1
• Desktop app backend launch (hermes serve spawned by Electron) — same crash, producing "Could not connect to hermes gateway" in the UI

The crash happens at gateway/run.py:7821.

Fix

Wrap faulthandler.enable() with a if sys.stderr is not None: guard. This preserves the faulthandler behavior on platforms where sys.stderr is available (Linux, macOS, Windows with TTY) while preventing the crash on headless child processes.

Verification

• Windows 10, gateway spawned as child process: before fix, crashes <1s; after fix, runs indefinitely
• Desktop app connects and loads successfully after reboot
• Feishu messaging gateway stable for 30+ minutes and responding to messages
• hermes gateway start returns success and process stays running
• No impact on Linux/macOS (sys.stderr is always available there)

[alt-glitch]

This was generated by AI during triage.

Duplicate of #71671: both guard the same gateway/run.py faulthandler.enable() call when sys.stderr is None. #71671 is the broader open fix with fallback logging and regression coverage.

[teknium1]

Thanks for the fix — this was a real bug and your guard was correct. It landed via PR #72304, which salvaged #71671 (the same fix submitted ~18h earlier, with a file-fallback so faulthandler stack dumps still work when stderr is missing, plus a regression test). Closing this one as a duplicate; appreciate the report and the diff.