feat(update): add opt-out for gateway shutdown notices

[metamindedu]

Summary

Windows Desktop/CLI updates intentionally pause running gateways before mutating the install. Today that planned stop follows the same notification path as manual or unexpected shutdowns, so active chats receive:

⚠️ Gateway shutting down — Your current task will be interrupted.

This PR makes that update-specific notice configurable while preserving existing behavior by default.

New setting

updates:
  gateway_shutdown_notification: true  # default

The setting is also exposed as Settings → Advanced → Update Shutdown Notifications in Hermes Desktop.

Setting	Update-initiated gateway stop	Other stops/restarts/failures
true (default)	Existing shutdown notice is sent	Existing behavior
false	Shutdown notice is suppressed	Existing behavior

Implementation

• Each profile's update helper reads its own config.yaml before writing the planned-stop marker.
• It sets suppress_notification: true only when that profile explicitly disables updates.gateway_shutdown_notification.
• The gateway honors suppression only when the live marker targets its own PID/start-time and passes the existing TTL checks.
• Missing, malformed, stale, foreign, or non-boolean values fail toward the historical visible behavior.
• Suppression affects only the user-facing update shutdown ping. Drain/interruption, resume_pending, cleanup, exit status, and post-update gateway restart behavior are unchanged.

Compatibility

• Default is true, so existing installs behave exactly as before.
• Legacy planned-stop markers omit the suppression field and remain visible.
• hermes gateway stop, service stops, normal restarts, and unexpected shutdowns do not set the update suppression flag and keep their existing notifications.

Related work / de-duplication

• Complements feat(gateway): suppress home-channel shutdown broadcast on flagged drains #54824: that merged change suppresses only the home-channel broadcast for flagged external drains and intentionally keeps active-session interruption pings. This PR covers the separate Windows Desktop/CLI updater planned-stop path and makes its policy user-selectable.
• Provides a narrower update-only control than the global notification settings requested in Feature request: option to disable/customize gateway shutdown notification #29846 and Feature request: config option to suppress gateway shutdown/restart notifications #21871.
• Does not change the gateway restart/recovery mechanics discussed in Telegram in-band hermes update can leave launchd gateway offline after drain timeout #56524.

Tests

• Python: 87 passed across updater quarantine/config behavior, planned-stop markers, restart-drain notifications, gateway shutdown, and config schema/default endpoints.
• Review follow-up: a lifecycle regression now exercises profile config → update marker → the registered shutdown signal handler → marker consumption/runner suppression flag → notification delivery for opt-out, default-visible, and legacy-marker cases.
• The lifecycle regression is fully in-process: it captures the registered callback and sends no OS signal or live gateway stop.
• Desktop UI: 20 passed in the Settings helper suite.
• Desktop TypeScript typecheck: passed.
• Targeted ESLint and Prettier checks: passed.
• Desktop production build: passed (assert-dist-built included).
• Ruff, py_compile, and git diff --check: passed.

The Desktop build emitted only existing non-blocking CSS/chunk-size warnings and reported zero dependency vulnerabilities after a clean root npm ci.

[teknium1]

Thanks for keeping the control narrowly scoped to update-initiated Windows gateway pauses. The current main path still writes an update planned-stop marker in hermes_cli/main.py:8881-8900, invokes it at hermes_cli/main.py:9196, and sends shutdown notices before drain at gateway/run.py:5815-5832 and gateway/run.py:8226-8228, so the premise remains current.

Problems

• The new tests stop short of the new integration boundary. tests/gateway/test_restart_drain.py directly sets runner._suppress_shutdown_notifications, and tests/gateway/test_status.py only probes the marker helper. Neither exercises the PR's gateway/run.py signal-handler sequence that reads the marker, consumes it, sets the runner flag, and then reaches notification delivery.

Suggested changes

• Add a lifecycle-level regression covering a fresh self-targeted marker with suppress_notification: true through the shutdown path, plus a legacy or false marker proving the existing notification still sends. This would validate the profile-config → marker → signal-handler → delivery chain required by the change.

Automated hermes-sweeper review.

[metamindedu]

Addressed the lifecycle coverage gap in 3c6018ebc7.

• Replaced the direct _suppress_shutdown_notifications = True test with an in-process lifecycle regression that starts at the real per-profile update config/marker writer.
• The test invokes the actual shutdown callback registered by start_gateway, verifies that the marker is consumed and the runner suppression flag is applied, then reaches the real notification-delivery method.
• Covered three compatibility cases: update opt-out suppresses the ping, the default-visible update setting still sends it, and a legacy marker without the field still sends it.
• The regression captures the callback and substitutes a notification-only runner.stop; it sends no OS signal and does not stop a live gateway.

Verification:

• Focused Python suite: 87 passed
• The three lifecycle cases also pass when applied to GitHub's current main + PR merge ref
• Ruff and git diff --check: passed