fix(notifications): list sort index + CAS operator Retry/Discard (P5-3, P5-4)

P5-3: add IX_Notifications_Created_NotificationId (CreatedAt DESC,
NotificationId DESC) — the Central UI Notification Outbox list page sorts on
exactly that pair, but no existing index leads unconditionally on CreatedAt,
so an unfiltered/lightly filtered page fell back to a full clustered-index
scan + sort on every COUNT + page request. Mirrors the Medium wave's
IX_SiteCalls_Created_TrackedOperationId migration + SQL twin pattern
faithfully, including the handwritten docs/plans/sql script.

P5-4: operator Retry/Discard was read-check-write keyed on NotificationId
only — a detached PipeTo task interleaving with the dispatcher's own write
(or a second concurrent operator action) could land between the read and
the write and get silently clobbered by the unconditional UpdateAsync,
stamping a Delivered row Discarded with stale fields. Adds
INotificationOutboxRepository.TryUpdateFromParkedAsync, a single-statement
compare-and-swap (WHERE Status == Parked) mirroring
SecuredWriteRepository.TryMarkApprovedAsync's CAS shape. NotificationOutboxActor's
RetryAsync/DiscardAsync now use the CAS write and, on a lost race, re-read
to report "notification already progressed to <Status>" instead of silently
overwriting whatever is there now.

Proof of failure: reverting only the actor's CAS usage while keeping the
repository addition reproduces the silent-overwrite bug — 7 tests fail,
including two new deterministic (non-sleep) race-proof tests that mock the
exact GetByIdAsync -> lost-CAS -> re-read sequence the finding describes.
P5-3 is perf-only; verified via migration/SQL-twin parity instead (no
runtime proof-of-failure is meaningful for an index).

src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/Configurations/NotificationOutboxConfiguration.cs

@@ -83,5 +83,23 @@ public class NotificationOutboxConfiguration : IEntityTypeConfiguration<Notifica
         builder.HasIndex(n => n.DeliveredAt)
             .HasDatabaseName("IX_Notifications_Delivered")
             .HasFilter("[Status] = 'Delivered'");
+
+        // Created_NotificationId backs the Central UI Notification Outbox list
+        // page's sort key — NotificationOutboxRepository.QueryAsync orders
+        // (CreatedAt DESC, NotificationId DESC) (NotificationId breaks CreatedAt
+        // ties for deterministic OFFSET paging). None of the indexes above lead
+        // unconditionally on CreatedAt: Status_NextAttemptAt requires an equality
+        // on Status first, SourceSiteId_CreatedAt requires an equality on
+        // SourceSiteId first, and IX_Notifications_Delivered is filtered to
+        // Status='Delivered' only. So an unfiltered (or lightly filtered) page
+        // fell back to a full clustered-index scan + sort on every COUNT + page
+        // request (arch-review 2026-08-19 P5-3, register row-35 class). With both
+        // key columns descending, a forward scan of this index already delivers
+        // rows in the requested order. Exact mirror of
+        // SiteCallEntityTypeConfiguration's IX_SiteCalls_Created_TrackedOperationId
+        // (2026-08-19, arch-review P5-2).
+        builder.HasIndex(n => new { n.CreatedAt, n.NotificationId })
+            .IsDescending(true, true)
+            .HasDatabaseName("IX_Notifications_Created_NotificationId");
     }
 }