hermes - 💡(How to fix) Fix Gateway status should expose platform health and recover stale adapters

Problem

A gateway process can be alive while a platform adapter is effectively dead. We saw this with QQBot: hermes gateway status showed a running Gateway PID, but QQBot had already lost its WebSocket and stopped receiving messages after a reconnect failure.

This makes health checks misleading: users see "gateway running" even though one configured platform is disconnected/stale.

Requested improvements

1. Expose per-platform transport health in hermes gateway status

   • show each configured/connected platform state, e.g. qqbot: connected/disconnected/reconnecting;
   • include last inbound event time, last successful heartbeat/reconnect, and last error where available;
   • distinguish "process running" from "all platform transports healthy".

2. Add a Gateway/platform watchdog

   • detect platform adapters that are disconnected/stale for more than a configurable threshold while the gateway process is still alive;
   • for restartable background installs, restart the gateway or platform adapter;
   • notify configured home channels before/after recovery attempts.

3. Improve QQBot reconnect logging

   • for gateway URL fetch failures, log exception type/repr and HTTP/network context where safe;
   • avoid empty messages such as Reconnect failed: Failed to get QQ Bot gateway URL: with no actionable detail.

4. Expand regression coverage

   • gateway URL temporary failure;
   • closed stale WebSocket after reconnect failure;
   • op7/4009 server reconnects;
   • gateway PID alive but platform transport disconnected/stale.

Context

PR #40198 fixes the immediate QQBot reconnect-loop bug for #31101. This issue tracks the broader observability and auto-recovery work so it can be developed separately without bloating the focused reconnect fix.

Observed live failure pattern

Gateway process: running
QQBot: WebSocket closed
QQBot: Reconnect failed while fetching gateway URL
After that: no new QQBot inbound messages until gateway restart

Expected behavior: status should reveal the platform-level failure, and watchdog/recovery should prevent a permanently silent QQBot while the gateway PID remains alive.