Fix two liveness false-negatives: MCP stdio subprocess + builtin cron ticker

[magnuslundstedt]

Two independent liveness checks report a live thing as dead; each surfaces as a spurious, user-facing failure. Both were found and fixed while running Hermes on macOS (launchd) and verified live.

1. tools/mcp_tool.py::_stdio_children_dead — inverted loop (commit 1)

Documented as "True when every stdio child we spawned has exited", but the loop returns True as soon as it finds a child that is still alive:

    if not psutil.pid_exists(pid):
        continue          # dead → check next
    return True           # ← a LIVE child wrongly reports "all dead"
    return False          # ← unreachable dead code

So the #81995 fast-fail path (_stdio_children_dead() → TimeoutError) aborts every stdio MCP tool call with MCP stdio subprocess for 'X' has exited while the servers are perfectly alive — the processes (and their watchdog/sudo wrappers) are running; only this client-side liveness check is wrong. It triggers whenever _stdio_child_pids is populated, taking down all stdio MCP tools at once.

Fix: return False as soon as any tracked child is alive; True only when none are — the correct meaning of the docstring.

2. hermes_cli/cron.py::_builtin_gateway_liveness — flaky PID scan (commit 2)

It decides whether the builtin cron ticker can fire via find_gateway_pids() (a PID scan). That scan can transiently return empty even while the gateway is up (e.g. right after a restart), so the in-gateway cronjob tool emits a false Gateway is not running — jobs won't fire while jobs are firing on schedule.

Fix: prefer the gateway runtime lock — it is held for exactly the gateway's lifetime (a reliable liveness signal) and short-circuits to True inside the gateway process, so the in-gateway check can never false-alarm. Falls back to the PID scan only when the lock reads inactive (the external-CLI path).

Both changes are minimal and self-contained.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #94339 for the MCP liveness repair: both reverse the same live-PID branch in _stdio_children_dead(). This PR also overlaps #94155's cron self-liveness work.

[kshitijk4poor]

Closing — both halves of this PR have now landed on main, with your cron commit merged via salvage:

• MCP half: duplicate of fix(mcp): un-invert the stdio children liveness check #94339 (@liuhao1024's canonical carrier — opened Aug 25, tested, community-verified across a dozen environments), which merged today. @alt-glitch's triage comment was correct on this. Your polarity analysis matched exactly — the inverted branch, the unreachable return False, and the "every stdio tool call aborted" blast radius.
• Cron half: your lock-first commit was the better mechanism of the competing fixes (it covers both the in-gateway self-excluded-PID case AND the post-restart transient scan miss, where fix(cron): stop the cronjob tool probing its own gateway as dead #94155 only fixed the former), so it was cherry-picked with your authorship preserved into fix(cron): trust the gateway runtime lock for builtin-ticker liveness (salvage #95947) #96214 (auto-merge armed). We added on top: a probe-failure hardening (crashing lock probe falls back to the pid scan instead of collapsing the tri-state), regression tests, and a widening of the same lock-first check to the hermes cron status sibling site in the same file.

Thanks for both finds — the live verification on launchd made the triage straightforward.