feat(GWC-37,WRK-32): refresh live alarm watch lists

docs/AlarmClientDiscovery.md

@@ -849,15 +849,20 @@ MXAccess item addresses for the `InAlarm`, `Acked`, `AckMsg`, and `Priority`
 subtags (confirmed AVEVA `AlarmExtension` field names, verified against the live
 ZB Galaxy `attribute_definition` rows).
 
-**The list is fixed for the life of the subscription.** The worker builds its
-subtag consumer from the targets `SubscribeAlarms` carried and keeps them until
-the subscription ends; a second `SubscribeAlarms` on a subscribed session is
-rejected, and the only way to replace the list — `UnsubscribeAlarms` then
-`SubscribeAlarms` — rebuilds `FailoverAlarmConsumer`, restarting it on the
-primary and discarding the warm standby state. Re-sending on a failover would
-therefore flap the feed rather than repair it. A monitor restart (a worker fault,
-or a gateway restart) re-resolves and re-sends, and that is the supported way to
-pick up Galaxy objects added since the monitor started.
+The gateway refreshes this list on the existing alarm reconciliation cadence
+and immediately before publishing a failover-to-subtag status. It compares a
+canonical fingerprint of all six target fields and sends
+`UpdateAlarmWatchListCommand` only for a material change. The worker constructs,
+subscribes, and attaches the replacement standby on its STA before swapping it
+in; a setup failure leaves the previous standby and the current primary/subtag
+mode unchanged. The gateway advances its acknowledged fingerprint only after an
+OK reply, so a rejected update remains degraded and is retried.
+
+`SubscribeAlarmsCommand.fallback_enabled` distinguishes an initially empty but
+discovery-enabled fallback from an intentionally alarm-manager-only
+subscription. In the former case the worker creates an empty standby that can be
+hot-swapped after discovery recovers. `ForceAlarmManager` leaves the field false
+and does not create a standby.
 
 Because the list is fixed, the resolution is **graded** rather than merely
 logged (GWC-37). `ResolveAsync` returns an `AlarmWatchListResolution` carrying
@@ -871,10 +876,10 @@ monitor folds the verdict into the alarm feed's `AlarmProviderStatus`:
   `AlarmProviderReasons.SubtagDiscoveryFailed` and the failure message, so a
   Galaxy Repository outage at startup is a standing status rather than one log
   line emitted possibly weeks before the failover that needs the list.
-- On the failover edge (`ApplyProviderModeChangeAsync` with `toMode == Subtag`)
-  the monitor re-resolves and compares against what it sent. A difference is
-  reported as `AlarmProviderReasons.SubtagWatchListStale` with both counts, on
-  the same status frame as the failover, because it cannot be applied.
+- If the worker rejects a material update, the monitor retains the previous
+  acknowledged fingerprint and reports
+  `AlarmProviderReasons.SubtagWatchListStale` with the rejection diagnostic.
+  The next reconciliation or failover edge retries the same resolved targets.
 
 `degraded` on the status is therefore the OR of "the subtag provider is the one
 serving" and "the subtag watch-list cannot cover anything". In `Auto` the second