fix(localdb): root-cause the soak disk-I/O failure + ship the hardening follow-ups

The Phase 2 soak's "LocalDb fails under load" blocker is NOT a product defect.
Root cause: host-side (macOS) sqlite3 reads of the live, bind-mounted WAL
databases. POSIX advisory locks do not propagate across the virtiofs boundary,
so the host reader believes it is the only connection, checkpoints on close and
resets the WAL to 0 bytes under the container. The container's still-mapped
WAL index then references frames that no longer exist and every subsequent
statement fails SQLITE_IOERR_SHORT_READ (522) -> primary code 10, permanently
until the process reopens the database.

Reproduced on demand both on the rig (one sqlite3 SELECT reset a 4.6 MiB WAL and
produced the first error one second later) and in a minimal python:3.12-alpine
repro with no LocalDb or .NET involved. Refuted the converse: a freshly-reopened
node sustained the full soak load 10+ minutes with zero errors.

The original brief's isolation was confounded - both nodes had been poisoned by
the same sampling pass, and a poisoned standby looks healthy only because it
issues almost no statements. Corrections annotated in place.

Hardening shipped alongside:
- SqliteErrorCodes.Describe: log SQLite primary AND extended codes at the
  LocalDb-adjacent catch sites (the missing extended code is what made the
  original diagnosis so slow).
- SiteAuditTelemetryActor: stop touching ActorContext across an await
  (NotSupportedException), with regression coverage.
- infra/reseed.sh: apply the MSSQL init scripts explicitly. The official
  mssql/server image does not implement /docker-entrypoint-initdb.d, so a fresh
  volume hung the reseed forever; compose mounts annotated as informational.

Deliberately NOT done: detect-and-reopen self-heal in SqliteLocalDb. It defends
only against external interference, which is now prevented at the source, and
same-kernel production readers see the locks correctly.

Build 0 warnings; SiteAuditTelemetryActorTests 9/9, SiteEventLogging 70/70.

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

infra/reseed.sh

@@ -82,12 +82,15 @@ if ! $SKIP_TEARDOWN; then
   done
   echo "  MSSQL ready."
 
-  echo "  Waiting for setup.sql to create ScadaBridgeConfig..."
-  until docker exec scadabridge-mssql /opt/mssql-tools18/bin/sqlcmd \
-        -S localhost -U sa -P 'ScadaBridge_Dev1#' -C \
-        -Q "IF DB_ID('ScadaBridgeConfig') IS NULL THROW 50000, 'not ready', 1;" \
-        >/dev/null 2>&1; do
-    sleep 2
+  # The official mcr.microsoft.com/mssql/server image does NOT implement
+  # /docker-entrypoint-initdb.d, so the compose-mounted init scripts never run
+  # on their own — waiting for them here hangs forever on a fresh volume.
+  # Apply them explicitly instead (all are idempotent).
+  echo "  Applying MSSQL init scripts (the mssql/server image has no initdb hook)..."
+  for f in mssql/setup.sql mssql/machinedata_seed.sql mssql/setup-env2.sql; do
+    echo "    $f"
+    docker exec -i scadabridge-mssql /opt/mssql-tools18/bin/sqlcmd \
+        -S localhost -U sa -P 'ScadaBridge_Dev1#' -C -b < "$SCRIPT_DIR/$f"
   done
   echo "  ScadaBridgeConfig present."