fix(config-db): EnableRetryOnFailure fleet-wide + execution-strategy wrap of the combined-telemetry dual-write

Installs SqlServerRetryingExecutionStrategy (5 retries, 30s cap) so transient SQL
faults retry transparently on every read-side path. Manual transactions aren't
auto-retried, so AuditLogIngestActor's idempotent dual-write is wrapped in an
explicit CreateExecutionStrategy().ExecuteAsync to become retriable. Verified
empirically that existing manual transactions (BundleImporter) are unaffected —
EF skips the strategy while a transaction is already active.

src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/Repositories/AuditLogRepository.cs

@@ -229,6 +229,13 @@ VALUES
     /// <inheritdoc />
     public async Task<long> SwitchOutPartitionAsync(DateTime monthBoundary, TimeSpan? commandTimeout = null, CancellationToken ct = default)
     {
+        // Task 12 (arch-review 04 S5) note: the drop-and-rebuild batch below runs via
+        // ExecuteSqlRaw with NO EF user-transaction — it carries its own server-side
+        // BEGIN TRANSACTION / TRY-CATCH / ROLLBACK — so the DbContext's retrying
+        // execution strategy (EnableRetryOnFailure) MAY auto-replay the whole batch on
+        // a transient fault. That replay is safe: every step is IF-EXISTS / IF-NOT-EXISTS
+        // guarded and the staging table is GUID-suffixed, so a re-run is idempotent.
+        //
         // Maintenance timeout in whole seconds (ADO.NET CommandTimeout unit). Null leaves the
         // provider default in place. See AuditLogPurgeOptions.MaintenanceCommandTimeoutMinutes /
         // arch-review 04 S2 for why the ~30s default is unsafe for the switch-out dance.