Resolve all 33 medium-severity architecture review findings

Second slice of the 2026-09-09 whole-system review remediation
(docs/plans/2026-09-09-arch-review.md §10), on top of the High slice 146a1323.

Runtime/devices: SR-2 alarm on-trigger integration scope; SR-3 correlated NativeAlarmActor
subscribe retry; SR-4 immutable audited DB target; SR-5 ordered InstanceActor stop/flush;
SR-12 rehydration fence; SR-13 S&F gate recheck per delivery; DC-4 no OPC UA security
downgrade; DC-5 alarm snapshot for every new subscriber; ORCH-1 sync-dispose joins the pump.

Management/UI: MG-2 site scope on audit tree + Flow Debugger Replay; MG-3 stale-probe memo
removed; MG-4 server-owned bulk-deploy deadline; UI-5 sandbox runs in a killable child
process (new CentralUI.SandboxWorker project); UI-14 bounded sandbox output/IPC.

Edge/audit: EI-1 relay audit ownership; EI-2 SkipBodyCapture suppresses error text; EI-3/EI-11
error-field redaction + caps; EI-4 single relay deadline, pre-execution-only retry; EI-5
authenticated relay provenance; EI-10 body cap before audit read.

Persistence/contracts: DL-1 global Instance.UniqueName unique index + conflict translation;
DL-2 DataConnection protocol config encrypted at rest (migration
20260909203046_EnforceGlobalInstanceNamesAndProtectProtocolConfiguration — coordinated
central upgrade, old binaries cannot read protected rows); DL-3 bounded Replay paging;
DL-6 cross-site Overwrite of a deployed instance rejected; XC-4 proto descriptor contract test.

Config/hygiene: XC-1 central listener isolation by local port; XC-2/XC-3 inert SMTP + cron
keys removed from rig settings; CM-2 env2 bootstrap guard enabled; DC-6 deploy site exit code;
DC-7 notifier retries only explicit standby rejection; XC-5 ClusterClient purged from docs.

Gates recorded in the report: build 0/0, 9 397 passed / 0 failed, rig redeployed on all
eight nodes with the migration applied. 46 Low findings remain open.

src/ZB.MOM.WW.ScadaBridge.DeploymentManager/DeploymentService.cs

@@ -568,6 +568,7 @@ public class DeploymentService
                 "Sending deployment {DeploymentId} for instance {Instance} to site {SiteId} (notify-and-fetch)",
                 prepared.DeploymentId, prepared.Instance.UniqueName, prepared.SiteIdentifier);
 
+            cancellationToken.ThrowIfCancellationRequested();
             var response = await _communicationService.RefreshDeploymentAsync(
                 prepared.SiteIdentifier, command, cancellationToken);
             return new SendOutcome(response, null);
@@ -1065,7 +1066,11 @@ public class DeploymentService
             // CancellationToken.None inside (see MarkDeploymentFailedAsync) so the
             // already-cancelled token cannot abort the cleanup writes themselves.
             await ReleasePreparedAsync(prepared, finalizedUpTo, user, ex);
-            throw;
+            if (ex is not OperationCanceledException || !cancellationToken.IsCancellationRequested) throw;
+            var recorded = results.Select(r => r.InstanceId).ToHashSet();
+            foreach (var pending in deployable.Where(i => !recorded.Contains(i.Id)))
+                results.Add(new InstanceDeploymentResult(pending.Id, pending.UniqueName, null, false,
+                    "Overall bulk deployment deadline exceeded; no further apply was scheduled."));
         }
 
         var summary = new SiteDeploymentSummary(
@@ -1149,11 +1154,9 @@ public class DeploymentService
     /// <para>
     /// <b>Cost.</b> The probe re-flattens on its own session rather than the
     /// batch's, so a fully-stale site pays one extra flatten per instance before
-    /// prepare re-flattens it for real. That is bounded by the probe's watermark
-    /// memo (unchanged graph ⇒ no flatten at all on the second and later calls, and
-    /// the Deployments page's staleness sweep warms the same memo), and it buys
-    /// back far more than it costs on the common mostly-unchanged site, which now
-    /// sends no site round-trips at all instead of one per instance.
+    /// prepare re-flattens it for real. Each request checks authoritative database
+    /// state because a peer central node can mutate configuration without bumping
+    /// this process's watermark. Unchanged instances still avoid site round-trips.
     /// </para>
     /// </summary>
     /// <param name="instance">The candidate instance.</param>