refactor(sf,site): both stores take ILocalDb instead of a connection string

Tasks 5 and 6 of the Phase 2 plan, committed together because their test
fallout is entangled — several fixtures construct both stores.

StoreAndForwardStorage and SiteStorageService now take ILocalDb. Connections
come from ILocalDb.CreateConnection(), which hands out an already-open,
pragma-configured connection carrying the zb_hlc_next() UDF the capture triggers
call; a raw connection would lack the UDF and every write to a replicated table
would fail closed. Deleted with the connection strings: S&F's
EnsureDatabaseDirectoryExists and its per-open busy_timeout pragma, and the site
service's BusyTimeoutFloorSeconds normalization — LocalDb owns all of it now.

DI: AddSiteRuntime's string overload is gone (nothing left to supply), so the
Host calls the no-arg form. ScadaBridge:Database:SiteDbPath and
StoreAndForwardOptions.SqliteDbPath survive only as the migrator's source
locations in Tasks 8/9.

Two things the plan did not anticipate, both worth reading:

1. FOUND A REAL LATENT DEFECT, from Phase 1, now fixed. The plan assumed
   directory creation simply moved to LocalDb along with file ownership. It did
   not: the LocalDb library never creates the parent directory, and
   SqliteLocalDb opens the file eagerly in its constructor — so a missing
   directory is a hard boot failure ("SQLite Error 14: unable to open database
   file"), not a degraded start. The default site config points at the RELATIVE
   path ./data/site-localdb.db, so any site node without a pre-existing data/
   directory fails to boot. The docker rig escapes only because its volume mount
   happens to create /app/data — a coincidence that would have hidden this until
   a bare-metal or fresh deployment. This has been latent since Phase 1 made
   LocalDb:Path required; deleting S&F's EnsureDatabaseDirectoryExists here
   would have widened it. Re-established the guarantee at the layer that now
   owns the path (SiteLocalDbDirectory.Ensure, called before AddZbLocalDb) and
   pinned it with SiteLocalDbDirectoryTests. Non-vacuity is not assumed: two
   tests written against the wrong assumption failed with exactly this
   SQLite Error 14 before the fix existed.

2. Test fallout was ~7x the plan's estimate. The plan named "fixtures" in one
   project; the constructor change actually reaches 40 files across 7 test
   projects, and most used Mode=Memory;Cache=Shared — which LocalDb has no
   equivalent for, so every one had to move to a real temp file. Rather than
   copy the Phase 1 TestLocalDb fixture into 7 projects, added a shared
   tests/ZB.MOM.WW.ScadaBridge.TestSupport library (not a test project) so the
   WAL-sidecar cleanup and the "real, not stubbed" rationale live in one place.

Retargeted rather than deleted, in both directions: the S&F WAL test now asserts
against the LocalDb-backed store (WAL genuinely is LocalDb's job), while the
directory-creation test moved to Host.Tests (that guarantee is NOT LocalDb's).
SiteStorageServiceTests.Initialize_EnablesWalJournalMode got the same treatment.
DeploymentManagerMediumFindingsTests induced a persistence failure via an
unopenable path, which no longer reaches the assertion since the fixture now
throws first; it induces the same failure shape via an uninitialized store.

Verified: full solution build 0 warnings; SiteRuntime 532, Host 318,
AuditLog 355, ExternalSystemGateway 142, HealthMonitoring 97,
StoreAndForward 153 — 1597 passed, 0 failed.

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

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

@@ -0,0 +1,59 @@
+using Microsoft.Extensions.Configuration;
+
+namespace ZB.MOM.WW.ScadaBridge.Host;
+
+/// <summary>
+/// Ensures the directory holding the consolidated site database (<c>LocalDb:Path</c>)
+/// exists before LocalDb opens the file.
+/// </summary>
+/// <remarks>
+/// <para>
+/// SQLite creates the database file on demand but never its parent directory, and
+/// <c>SqliteLocalDb</c> opens the file eagerly in its constructor — so a missing directory
+/// is a hard boot failure ("SQLite Error 14: unable to open database file"), not a degraded
+/// start. Neither the LocalDb library nor its options validation does this.
+/// </para>
+/// <para>
+/// The guarantee previously lived in <c>StoreAndForwardStorage.EnsureDatabaseDirectoryExists</c>,
+/// which created the directory for the store's own SQLite file. Once that file was folded
+/// into the consolidated database the store stopped owning a path, so the guarantee had to
+/// be re-established at the layer that now configures the path: the site host.
+/// </para>
+/// <para>
+/// It matters because the default site configuration uses the <i>relative</i> path
+/// <c>./data/site-localdb.db</c>. The docker rig never noticed the gap only because its
+/// volume mount happens to create <c>/app/data</c>.
+/// </para>
+/// </remarks>
+public static class SiteLocalDbDirectory
+{
+    /// <summary>
+    /// Creates the directory containing <c>LocalDb:Path</c> when it does not already exist.
+    /// No-op when the key is unset.
+    /// </summary>
+    /// <remarks>
+    /// Best-effort by design: if the directory cannot be created (permissions, read-only
+    /// mount) this stays silent and lets LocalDb raise the real error, which names the
+    /// actual path and is a better diagnostic than anything thrown from here.
+    /// </remarks>
+    /// <param name="config">Configuration carrying <c>LocalDb:Path</c>.</param>
+    public static void Ensure(IConfiguration config)
+    {
+        ArgumentNullException.ThrowIfNull(config);
+
+        var path = config["LocalDb:Path"];
+        if (string.IsNullOrWhiteSpace(path))
+            return;
+
+        try
+        {
+            var directory = Path.GetDirectoryName(Path.GetFullPath(path));
+            if (!string.IsNullOrEmpty(directory) && !Directory.Exists(directory))
+                Directory.CreateDirectory(directory);
+        }
+        catch (Exception ex) when (ex is IOException or UnauthorizedAccessException or ArgumentException)
+        {
+            // Deliberately swallowed — see the remarks above.
+        }
+    }
+}

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

@@ -65,10 +65,13 @@ public static class SiteServiceRegistration
         services.AddSingleton<ISiteIdentityProvider, SiteIdentityProvider>();
         services.AddSingleton<IHealthReportTransport, AkkaHealthReportTransport>();
 
-        // Site-only components — AddSiteRuntime registers SiteStorageService with SQLite path
-        // and site-local repository implementations (IExternalSystemRepository, INotificationRepository)
-        var siteDbPath = config["ScadaBridge:Database:SiteDbPath"] ?? "site.db";
-        services.AddSiteRuntime($"Data Source={siteDbPath}");
+        // Site-only components — AddSiteRuntime registers SiteStorageService and the
+        // site-local repository implementations (IExternalSystemRepository,
+        // INotificationRepository). It takes no connection string any more:
+        // SiteStorageService persists to the consolidated LocalDb database registered
+        // just below (LocalDb:Path). ScadaBridge:Database:SiteDbPath survives only as
+        // the legacy migrator's source location.
+        services.AddSiteRuntime();
 
         // Consolidated site database (LocalDb Phase 1). Holds OperationTracking and
         // site_events as replicated tables so the pair stops losing them on failover.
@@ -78,6 +81,18 @@ public static class SiteServiceRegistration
         // initiator idles.
         //
         // Design: scadaproj docs/plans/2026-07-19-scadabridge-localdb-design.md
+        //
+        // Create the parent directory FIRST. SQLite creates the database file on demand
+        // but not its directory, and neither the LocalDb library nor its options
+        // validation does this — SqliteLocalDb's constructor opens the file eagerly, so a
+        // missing directory is a hard boot failure ("SQLite Error 14: unable to open
+        // database file"), not a degraded start. The default site path is the relative
+        // "./data/site-localdb.db", so this bites any site node whose data directory has
+        // not been pre-created; the docker rig only escapes it because the volume mount
+        // creates /app/data. StoreAndForwardStorage used to do this for its own file
+        // (EnsureDatabaseDirectoryExists) and that guarantee has to keep existing
+        // somewhere now that LocalDb owns the file.
+        SiteLocalDbDirectory.Ensure(config);
         services.AddZbLocalDb(config, db => SiteLocalDbSetup.OnReady(db, config));
 
         // The replication engine, likewise unconditional but INERT by default: with no