fix(adminui): wire Test Connect probes + live panels on admin-only nodes

Both bugs surfaced only on split-role deployments (the MAIN cluster's
admin-only nodes), where the AdminUI runs without the driver role.

- Test Connect returned "No probe registered" for every driver: the
  IDriverProbe set was registered only under the driver role, but the
  admin-operations singleton that consumes it is pinned to admin. Extract
  AddOtOpcUaDriverProbes() (idempotent via TryAddEnumerable) and call it
  in the hasAdmin path too.

- Live driver-status/alerts/script-log panels showed "SignalR error:
  Connection refused": these Blazor Server components opened a HubConnection
  to their own hub via the browser's public URL, which server-side code
  can't reach behind Traefik (host :9200 -> container :9000). Read the
  in-process source directly instead -- DriverStatus via
  IDriverStatusSnapshotStore.SnapshotChanged, Alerts/ScriptLog via a new
  IInProcessBroadcaster<T>. Fleet status was unaffected (reads DB/ActorSystem).

Adds unit tests for probe registration, the snapshot-store event, and the
broadcaster.

src/Server/ZB.MOM.WW.OtOpcUa.Host/Drivers/DriverFactoryBootstrap.cs

@@ -1,4 +1,5 @@
 using Microsoft.Extensions.DependencyInjection;
+using Microsoft.Extensions.DependencyInjection.Extensions;
 using Microsoft.Extensions.Logging;
 using ZB.MOM.WW.OtOpcUa.Core.Abstractions;
 using ZB.MOM.WW.OtOpcUa.Core.Hosting;
@@ -23,8 +24,10 @@ using HistorianProbe = Driver.Historian.Wonderware.Client.WonderwareHistorianDri
 ///     over it. Replaces the F7 seam's <c>NullDriverFactory</c> default so deploys actually
 ///     materialise real <see cref="IDriver"/> instances on driver-role nodes.
 ///
-///     Skipped entirely on admin-only nodes — they never run drivers, so the registry doesn't
-///     need to exist (Program.cs guards via the <c>hasDriver</c> flag).
+///     The factory registry is skipped on admin-only nodes — they never run drivers, so it doesn't
+///     need to exist (Program.cs guards via the <c>hasDriver</c> flag). The driver <em>probe</em>
+///     set is the exception: it backs the AdminUI Test Connect button and so must also be wired on
+///     admin nodes — see <see cref="AddOtOpcUaDriverProbes"/>.
 /// </summary>
 public static class DriverFactoryBootstrap
 {
@@ -46,16 +49,42 @@ public static class DriverFactoryBootstrap
         services.AddSingleton<IDriverFactory>(sp =>
             new DriverFactoryRegistryAdapter(sp.GetRequiredService<DriverFactoryRegistry>()));
 
-        // One IDriverProbe per driver type — wired into AdminOperationsActor via DI enumeration.
-        services.AddSingleton<IDriverProbe, ModbusProbe>();
-        services.AddSingleton<IDriverProbe, AbCipProbe>();
-        services.AddSingleton<IDriverProbe, AbLegacyProbe>();
-        services.AddSingleton<IDriverProbe, S7Probe>();
-        services.AddSingleton<IDriverProbe, TwinCATProbe>();
-        services.AddSingleton<IDriverProbe, FocasProbe>();
-        services.AddSingleton<IDriverProbe, OpcUaProbe>();
-        services.AddSingleton<IDriverProbe, GalaxyProbe>();
-        services.AddSingleton<IDriverProbe, HistorianProbe>();
+        // Driver nodes also carry the probe set so a fused admin,driver node has it; the admin-only
+        // case is covered by Program.cs calling AddOtOpcUaDriverProbes() in the hasAdmin block.
+        services.AddOtOpcUaDriverProbes();
+
+        return services;
+    }
+
+    /// <summary>
+    ///     Register one <see cref="IDriverProbe"/> per driver type. These back the AdminUI's
+    ///     "Test Connect" button: the <c>admin-operations</c> cluster singleton resolves
+    ///     <see cref="IEnumerable{T}"/> of <see cref="IDriverProbe"/> and dispatches by DriverType.
+    ///     <para>
+    ///     That singleton is role-pinned to <c>admin</c>, so this MUST be wired on admin nodes —
+    ///     including admin-only nodes that lack the <c>driver</c> role (e.g. the MAIN cluster's
+    ///     admin-a/admin-b). Probes are lightweight (cheap connect, no persistent state) and don't
+    ///     need the driver-factory registry, so they register independently of
+    ///     <see cref="AddOtOpcUaDriverFactories"/>.
+    ///     </para>
+    ///     <para>
+    ///     Uses <c>TryAddEnumerable</c> so a fused admin,driver node — which reaches this from both
+    ///     the driver-factory path and the admin path — registers each probe exactly once. A
+    ///     duplicate would make the singleton's <c>ToDictionary(p =&gt; p.DriverType)</c> throw.
+    ///     </para>
+    /// </summary>
+    /// <param name="services">The service collection to register driver probes with.</param>
+    public static IServiceCollection AddOtOpcUaDriverProbes(this IServiceCollection services)
+    {
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, ModbusProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, AbCipProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, AbLegacyProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, S7Probe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, TwinCATProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, FocasProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, OpcUaProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, GalaxyProbe>());
+        services.TryAddEnumerable(ServiceDescriptor.Singleton<IDriverProbe, HistorianProbe>());
 
         return services;
     }