Merge fix/c3-session-lifecycle: GWC-32 WorkerClient dispose is terminal, GWC-34 attach-after-dispose throws SessionNotReady, GWC-37 subtag watch-list coverage graded on provider status + re-resolved at failover edge

gateway.md

@@ -249,6 +249,22 @@ monitoring (forced)") when subtag mode is the configured `Fallback:Mode=ForceSub
 as a fault. Metrics: `mxgateway.alarms.provider_mode` gauge (1 = alarmmgr,
 2 = subtag) and `mxgateway.alarms.provider_switches` counter.
 
+**Standby-coverage visibility:** `degraded` also covers the case where the alarm
+manager is serving normally but the subtag standby behind it could not cover
+anything — a watch-list that resolved to zero targets, or Galaxy Repository
+discovery that was enabled and failed. That condition used to be a single startup
+log line, invisible until the failover that needed the standby found it empty; it
+is now a standing `AlarmProviderStatus` reason
+(`AlarmProviderReasons.SubtagWatchListEmpty` / `SubtagDiscoveryFailed`) carried on
+the feed and rendered as the amber `Alarm Manager (no subtag standby)` badge, which
+keeps the failover label from naming the wrong live provider. The watch-list the
+worker holds is fixed for the life of the subscription, so on the failover edge the
+monitor re-resolves and reports a difference
+(`AlarmProviderReasons.SubtagWatchListStale`, with both counts) rather than
+re-sending it — re-sending would rebuild the failover consumer on the primary that
+just failed. A monitor restart re-resolves and re-sends. See
+`docs/AlarmClientDiscovery.md`.
+
 **Truncated-snapshot visibility:** `GetXmlCurrentAlarms2` caps its reply at
 `MxGateway:Alarms:MaxAlarmsPerFetch` and offers no confirmed "more available"
 flag, so a reply holding exactly the cap is treated as truncated. On such a