fix(gateway): notify home channels after cold start and crash recovery

[plcunha]

1|## Summary
2|
3|Notify configured home channels when the gateway becomes available after a true cold start or crash recovery, while preserving mode-specific behavior for chat-originated /restart.
4|
5|This PR has been re-scoped against current main in response to review. It no longer duplicates Telegram adapter readiness or dashboard PID-liveness logic already implemented upstream.
6|
7|## Current behavior
8|
9|Current main sends the home-channel lifecycle notification only for a non-chat planned restart. A cold service start or crash recovery completes silently even when a home channel is configured.
10|
11|## Change
12|
13|- Send the existing lightweight home-channel startup notification when no chat-originated restart marker was present.
14|- Keep chat /restart scoped to its originating chat/topic and suppress a duplicate home-channel broadcast.
15|- Preserve planned-restart marker cleanup.
16|- Treat home-channel notification delivery as best effort so it cannot abort gateway startup.
17|
18|## Explicitly not included
19|
20|- No runner-level Telegram _send_path_degraded polling; adapter readiness remains owned by the Telegram adapter.
21|- No runtime-status PID override; dashboard liveness remains owned by resolve_gateway_liveness() and get_runtime_status_running_pid().
22|
23|## Tests
24|
25|Added mode-specific regressions for:
26|
27|1. cold/crash-recovery startup broadcasts exactly through the home-channel path;
28|2. chat-originated /restart does not also broadcast to home.
29|
30|Validation on current origin/main:
31|
32|- 21 passed across startup and restart-notification suites
33|- Ruff passed
34|- py_compile passed
35|- git diff --check passed
36|
37|## Policy note
38|
39|This intentionally isolates the remaining maintainer decision identified by the sweeper: whether configured home channels should receive an online notification after cold start/crash recovery. The implementation and tests are now limited to that policy choice.
40|

[alt-glitch]

This was generated by AI during triage.

Related to #69240: both address Telegram startup readiness, but this PR waits after connection for the send path while #69240 makes initial polling readiness part of connection establishment. Maintainer decision needed before combining the policies.

[plcunha]

Found and fixed a lifecycle-notification race in 1dab4c7d9: _send_restart_notification() consumes .restart_notify.json in finally, so re-reading the marker afterward always looked like a cold start and triggered an additional Home broadcast after chat-originated /restart. Startup now uses the pre-send snapshot. Added an end-to-end startup regression test. Validation: 13 startup tests + 153 restart/status tests passed locally; ruff and git diff --check are clean. Hosted CI is fully green (26 successful checks, no failures or pending checks).

[teknium1]

Thanks for investigating the startup-notification failures. Two parts of this PR have since been addressed on current main at more appropriate boundaries.

Problems

• Telegram cold startup now passes require_progress=not is_reconnect at plugins/platforms/telegram/adapter.py:4041-4048; its strict gate waits for generation-scoped getUpdates progress before success at :2419-2459 (c8ff720508). The runner-level _send_path_degraded polling is therefore redundant.
• Dashboard liveness already validates runtime PIDs through resolve_gateway_liveness() in hermes_cli/web_server.py:2995-3005 and get_runtime_status_running_pid() in gateway/status.py:1293-1334.
• The all-start broadcast remains a policy decision: current main explicitly limits it to non-chat planned restarts at gateway/run.py:10941-10952.

Suggested changes

• Re-scope any salvage to the cold-start/crash-recovery broadcast policy after maintainer agreement, with mode-specific delivery and duplicate-suppression tests.
• Keep the existing adapter readiness and dashboard-liveness paths rather than duplicating them in GatewayRunner or read_runtime_status().

Automated hermes-sweeper review.

[alt-glitch]

This was generated by AI during triage.

Related to #62512 and #27870. Current main already contains the Telegram-readiness half; this PR's remaining cold/crash home-channel broadcast is a maintainer policy decision.

[plcunha]

Reconciled with current main and re-scoped on head fbf193c8d. The Telegram readiness and PID-liveness portions already implemented upstream were removed from the net diff. The PR now covers only the remaining cold-start/crash-recovery home-channel notification policy, while chat-originated /restart continues to notify only its originating chat/topic and avoids a duplicate Home broadcast. Startup regressions passed locally; the branch is mergeable with 27 successful checks and no failures. The title/body now describe this narrower policy decision explicitly.