fix(mesh): resolve dialer + PSK provider lazily — central boots again

Phase 1A live gate defect 4. Neither central node booted on this branch,
in ANY transport mode:

  Akka.Hosting.MissingActorRegistryEntryException: No actor registered
  for key ...ControlPlane.AuditWriterActorKey
     at AdminUI.Audit.ActorAuditWriter..ctor(ActorRegistry registry)
     at ControlPlane.ServiceCollectionExtensions.<WithOtOpcUaControlPlaneSingletons>

WithOtOpcUaControlPlaneSingletons' first WithActors starter resolved
IMeshCommandDialer and IMeshPskProvider eagerly for the Props. Their
graph reaches back into the registry — dialer -> IMeshPskProvider ->
ISecretResolver -> AddZbSecrets -> IAuditWriter -> ActorAuditWriter,
whose ctor calls registry.Get<AuditWriterActorKey>() — and
WithSingleton<AuditWriterActorKey> is registered ~60 lines LATER in the
same builder. Boot died before the entry existed. Mode-independent: the
resolve happened before anything consulted MeshTransport:Mode, so Dps
(the default, and the rollback target) died exactly like Grpc.

Both dependencies now arrive as Func<> and are invoked in PreStart, by
which point the host is fully built — the same shape, for the same
class of reason, as the coordinator proxy Func one argument earlier.
PreStart re-resolves on restart rather than caching across one; both
are container singletons, so a restart gets the same instances. A
resolution throw is caught and logged rather than propagated: a throw
out of PreStart is an actor failure, the supervisor answers it with a
restart, and a broken DI graph is not transient — that is an unbounded
restart loop that would take the transport-independent ack path down
with it.

Regression pin: ControlPlaneStarterOrderTests boots a REAL admin host
through WithOtOpcUaClusterBootstrap + WithOtOpcUaControlPlaneSingletons
in production starter order, with the production graph from
IMeshCommandDialer down to a registry-bound IAuditWriter, and asserts
StartAsync itself — the failure occurs while the builder's starters
execute, so building a ServiceProvider and resolving by hand cannot
reproduce it. Verified RED against the eager resolve: 3/3 modes fail
with MissingActorRegistryEntryException. A second fact pins that the
deferral did not become 'never resolved' — the actor must resolve the
provider from the container and drive it through the contact refresh,
signalled by a TaskCompletionSource (PreStart runs on the actor thread
and the contact load is a piped DB read, so no synchronous assertion
after StartAsync is correct).

Why nothing caught this: the dialer's container-activation test resolves
from a collection with no secrets registration, so its graph stops one
hop in; the actor facts inject fakes and never touch DI; and the
existing whole-host boots register no mesh provider, so the eager
lookups returned null and walked nothing.

Two aggravators recorded by the gate, no code here: the failed process
did not exit (docker Up while /health/ready 503s — Phase 2 readiness
concern, tracked), and this is the third instance of the same
eager-resolve-during-AddAkka class after scadaproj#1 and mesh Phase 6's
IClusterRoleInfo boot crash.

ControlPlane.Tests 236 -> 240, Host.Tests 92, Cluster.Tests 184,
0 warnings in every touched project.

src/Server/ZB.MOM.WW.OtOpcUa.ControlPlane/ServiceCollectionExtensions.cs

@@ -66,14 +66,20 @@ public static class ServiceCollectionExtensions
             var dbFactory = resolver.GetService<IDbContextFactory<OtOpcUaConfigDbContext>>();
             var options = resolver.GetService<IOptions<MeshTransportOptions>>().Value;
 
+            // Captured, NOT resolved. Resolving the mesh dialer or PSK provider here made every
+            // central node fail to boot in every transport mode: their graph is dialer →
+            // IMeshPskProvider → ISecretResolver → AddZbSecrets → IAuditWriter → ActorAuditWriter,
+            // whose constructor calls registry.Get<AuditWriterActorKey>() — and WithSingleton
+            // <AuditWriterActorKey> is registered further down THIS builder, so the entry does not
+            // exist while this starter runs. The actor invokes these in PreStart instead, by which
+            // point the host is built. Same shape, same reason, as the coordinator Func below.
+            //
             // Through IServiceProvider rather than the Akka resolver, deliberately: these two are
             // OPTIONAL (Grpc mode only, and admin-role only within that), and GetService's
             // null-for-absent contract is the thing being relied on. The Akka resolver's
             // GetService<T> makes no such promise, and this same block runs in test harnesses whose
             // service collections register neither.
             var serviceProvider = resolver.GetService<IServiceProvider>();
-            var dialer = serviceProvider.GetService<IMeshCommandDialer>();
-            var pskProvider = serviceProvider.GetService<IMeshPskProvider>();
 
             var actor = system.ActorOf(
                 CentralCommunicationActor.Props(
@@ -85,8 +91,8 @@ public static class ServiceCollectionExtensions
                     () => registry.TryGet<ConfigPublishCoordinatorKey>(out var coordinator)
                         ? coordinator
                         : null,
-                    dialer,
-                    pskProvider),
+                    () => serviceProvider.GetService<IMeshCommandDialer>(),
+                    () => serviceProvider.GetService<IMeshPskProvider>()),
                 MeshPaths.CentralCommunicationName);
 
             // Registered unconditionally, in both transport modes. Under Dps nothing dials it, and