fix(management): CAS-guard secured-write reject (WHERE Status='Pending') so reject can never falsify an executed two-person write (arch-review 2026-08-19 P6-1 High)

Reject read the row as Pending, then landed a blind full-row UpdateAsync. A
concurrent approve could win its own Pending->Approved CAS in that gap and enter
the multi-second WriteTagAsync relay; the reject's update then stamped
Status/ExecutedAtUtc/ExecutionError to Rejected mid-relay, so the two-person-control
record said Rejected for a write that physically executed at the plant. Works
cross-node (both centrals share one MS SQL).

- ISecuredWriteRepository/SecuredWriteRepository: new TryMarkRejectedAsync,
  mirroring TryMarkApprovedAsync exactly (conditional UPDATE ... WHERE
  Status='Pending', writes only the columns the reject transition owns). No schema
  change, no migration, no rowversion column.
- HandleRejectSecuredWrite: uses the CAS; on loss re-reads the row and returns the
  status that actually won (same UX shape as approve's lost-race error), and emits
  the SecuredWriteReject audit row ONLY on a won CAS.
- Audited the other lifecycle writes: approve/reject/expiry (inline + the
  opportunistic list sweep) now ALL transition only out of Pending, so winning the
  approve CAS gives that leg exclusive ownership of the row and its post-relay
  Executed/Failed update stays safe as an unconditional write. Documented in place.
- Tests: repository-level approve-vs-reject races in both orders (exactly one wins,
  loser false, row reflects the winner only) plus reject-vs-expiry; handler-level
  lost-race reject (conflict error, no write, no audit row) and approve on an
  already-rejected row (no CAS, no relay, no audit).

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

@@ -113,6 +113,35 @@ WHERE Id = {id}
         return rowsAffected == 1;
     }
 
+    /// <inheritdoc />
+    public async Task<bool> TryMarkRejectedAsync(
+        long id,
+        string verifierUser,
+        string? verifierComment,
+        DateTime decidedAtUtc,
+        CancellationToken ct = default)
+    {
+        // Single-statement compare-and-swap, mirroring TryMarkApprovedAsync exactly.
+        // A blind full-row UpdateAsync here used to be able to land AFTER a concurrent
+        // approve had won its own CAS and while its multi-second WriteTagAsync relay was
+        // still in flight — stamping the row Rejected even though the plant write was
+        // physically executing, i.e. falsifying the two-person-control record
+        // (arch-review 2026-08-19 P6-1). The conditional WHERE Status='Pending' makes
+        // reject win only from Pending, so approve and reject can never both transition
+        // one row. Only the columns the reject transition owns are written.
+        var rowsAffected = await _context.Database.ExecuteSqlInterpolatedAsync(
+            $@"UPDATE dbo.PendingSecuredWrites
+SET Status = 'Rejected',
+    VerifierUser = {verifierUser},
+    VerifierComment = {verifierComment},
+    DecidedAtUtc = {decidedAtUtc}
+WHERE Id = {id}
+  AND Status = 'Pending';",
+            ct);
+
+        return rowsAffected == 1;
+    }
+
     /// <inheritdoc />
     public async Task<bool> TryMarkExpiredAsync(long id, DateTime expiredAtUtc, CancellationToken ct = default)
     {