feat(secrets): opt-in SQL-Server hub replication for the host secret store

Routes both host-container secret registrations (central role in Program.cs,
site role in SiteServiceRegistration) through a new SecretsRegistration
composition seam that optionally enables ZB.MOM.WW.Secrets.Replicator.SqlServer
hub-replication mode: each node keeps a LOCAL store that syncs bidirectionally
with a shared central SQL hub, so a site cluster keeps resolving secrets
straight through a WAN outage to central.

OPT-IN GATE (the load-bearing part). AddZbSecretsSqlServerReplication validates
its options EAGERLY at registration time, so wiring it unconditionally would
make ScadaBridge fail to START anywhere Secrets:SqlServer:ConnectionString is
unset -- every dev box, every docker node, every existing deployment. The
SQL-Server package is therefore only touched when BOTH Secrets:Replication:
Enabled is true AND a non-blank connection string is present; otherwise the
registration is byte-identical to the previous plain AddZbSecrets call.
Enabled-without-a-connection-string falls back to local-only and logs a warning
rather than failing the node or silently looking healthy.

BOOTSTRAP CYCLE. The hub connection string is itself a secret and can never come
from the hub -- a node cannot read the hub to learn how to reach the hub. It must
arrive from outside the replicated set: an environment variable, or a ${secret:}
reference seeded in that node's own LOCAL store. appsettings.json therefore ships
ConnectionString empty with a _comment saying so (leaf keys starting with '_' are
skipped by the reference expander, verified in SecretReferenceExpander). No real
connection string is committed. The pre-host ${secret:} expander in Program.cs is
deliberately left on a plain local SQLite store for the same reason.

Per-node docker appsettings are intentionally NOT modified -- replication stays
off there for now.

Tests written before the wiring and confirmed red first (2 failed / 4 passed),
green after (6/6). They BUILD a container and RESOLVE from it rather than
asserting over ServiceDescriptors: a decorator can look correct as a descriptor
list and still throw on first resolve because the undecorated concrete store it
depends on is missing -- that exact defect shipped once in this library with all
descriptor-level tests green, so the undecorated SqliteSecretStore gets its own
resolution test.

Verified: Host.Tests 285/285 pass; full build (all projects except the
pre-existing AngleSharp NU1902 CentralUI.Tests restore break) 0 warnings,
0 errors.

Claude-Session: https://claude.ai/code/session_01BL2Vu1ESDQ9SCN4gVKkdts

src/ZB.MOM.WW.ScadaBridge.Host/SecretsRegistration.cs

@@ -0,0 +1,92 @@
+using ZB.MOM.WW.Secrets.DependencyInjection;
+using ZB.MOM.WW.Secrets.Replicator.SqlServer.DependencyInjection;
+
+namespace ZB.MOM.WW.ScadaBridge.Host;
+
+/// <summary>
+/// Single composition-root entry point for the host container's secret store, shared by the
+/// central-role registrations in <c>Program.cs</c> and the site-role registrations in
+/// <see cref="SiteServiceRegistration"/> so both roles wire secrets identically.
+/// </summary>
+/// <remarks>
+/// <para>
+/// Clustered replication is <b>opt-in and off by default</b>. ScadaBridge is hub-and-spoke — one
+/// central cluster plus N separate site clusters — and hub mode gives each node a LOCAL store that
+/// syncs bidirectionally with a shared central SQL hub, so a site keeps resolving secrets straight
+/// through a WAN outage.
+/// </para>
+/// <para>
+/// The gate is not a style preference. <c>AddZbSecretsSqlServerReplication</c> validates its options
+/// EAGERLY at registration time, so calling it unconditionally would throw at startup on every node
+/// where <c>Secrets:SqlServer:ConnectionString</c> is unset — which is every dev box, every docker
+/// node and every existing deployment. Both the explicit <c>Secrets:Replication:Enabled</c> flag and
+/// a non-blank connection string are therefore required before the SQL-Server package is touched at
+/// all; otherwise this is byte-for-byte the plain local-SQLite registration it has always been.
+/// </para>
+/// <para>
+/// <b>Bootstrap constraint.</b> The hub connection string is itself a secret, and it can never come
+/// from the hub — a node cannot read the hub to learn how to reach the hub. It must arrive from
+/// outside the replicated set: an environment variable, or a <c>${secret:}</c> reference that is
+/// seeded in that node's own LOCAL store (the pre-host expander in <c>Program.cs</c> runs against a
+/// plain local SQLite store before the host container exists, so such a reference does resolve).
+/// That expander is deliberately left un-replicated for exactly this reason.
+/// </para>
+/// </remarks>
+public static class SecretsRegistration
+{
+    /// <summary>Configuration section holding the core secrets options.</summary>
+    public const string SecretsSectionPath = "Secrets";
+
+    /// <summary>Configuration section holding the SQL-Server hub options.</summary>
+    public const string SqlServerSectionPath = "Secrets:SqlServer";
+
+    /// <summary>Configuration key gating clustered replication. Absent or false = off.</summary>
+    public const string ReplicationEnabledKey = "Secrets:Replication:Enabled";
+
+    /// <summary>Configuration key holding the shared SQL-Server hub connection string.</summary>
+    public const string HubConnectionStringKey = "Secrets:SqlServer:ConnectionString";
+
+    /// <summary>
+    /// Registers the host container's secret store: a plain local SQLite store by default, or a
+    /// local store replicating against a shared SQL-Server hub when replication is explicitly
+    /// enabled and a hub connection string is present.
+    /// </summary>
+    /// <param name="services">The service collection to register into.</param>
+    /// <param name="config">Application configuration for options binding.</param>
+    /// <returns>The same <paramref name="services"/> instance, for chaining.</returns>
+    public static IServiceCollection AddScadaBridgeSecrets(
+        this IServiceCollection services,
+        IConfiguration config)
+    {
+        ArgumentNullException.ThrowIfNull(services);
+        ArgumentNullException.ThrowIfNull(config);
+
+        var enabled = config.GetValue<bool>(ReplicationEnabledKey);
+        var connectionString = config[HubConnectionStringKey];
+
+        if (enabled && !string.IsNullOrWhiteSpace(connectionString))
+        {
+            // Registers the validated hub options, decorates ISecretStore with
+            // ReplicatingSecretStore, and adds the hub-schema migration + bidirectional sweep
+            // hosted services. Calls AddZbSecrets internally — do NOT also call it here.
+            return services.AddZbSecretsSqlServerReplication(
+                config, SecretsSectionPath, SqlServerSectionPath);
+        }
+
+        if (enabled)
+        {
+            // Asked for replication but gave nothing to replicate against. Falling back to the
+            // local-only store keeps the node up, but it is silently NOT participating in the
+            // cluster, so say so loudly rather than letting it look healthy.
+            Serilog.Log.Warning(
+                "{Key} is true but {ConnKey} is empty — clustered secret replication is DISABLED "
+                    + "and this node's secrets are local-only. The hub connection string cannot come "
+                    + "from the hub itself; supply it via environment variable or seed it in this "
+                    + "node's local store.",
+                ReplicationEnabledKey,
+                HubConnectionStringKey);
+        }
+
+        return services.AddZbSecrets(config, SecretsSectionPath);
+    }
+}