docs(code-review): re-review 17 changed modules at 1f9de8a2 — 8 new findings

Re-reviewed the modules whose source changed since the last review baseline
(full-review remediation fd618cf1 + InboundAPI Database-helper fixes b3c90143),
focused on whether the fixes are sound and regression-free. 9 of 17 modules
clean; 8 new findings (0 Critical, 0 High, 4 Medium, 4 Low), all code-verified
by the orchestrator before recording:

- DataConnectionLayer-029 (Med): DCL-023's unsubscribe-clears-in-flight reopens a
  double-subscribe window that leaks an orphaned alarm feed; the alarm completion
  handler overwrites the subscription id without the tag-path guard at line 908.
- InboundAPI-031 (Med): WaitForAttribute's 5s grace backstop is tighter than the
  CommunicationService Ask's timeout+IntegrationTimeout (30s) round-trip slack, so
  a slow-but-valid timed-out 'false' arriving in the 5-30s window is cancelled into
  an unhandled OperationCanceledException/500 (contradicts spec 6 + its own comment).
- SiteRuntime-032 (Med): SiteRuntime-029's wasPresent guard skips the deployed-count
  decrement when deleting a DISABLED instance (absent from both maps), drifting the
  health-dashboard tally; self-heals on singleton restart (observational, hence Med).
- StoreAndForward-028 (Med): StoreAndForward-025 resets the register-guard but not
  _bufferedCount, so a same-instance Stop->Start re-seeds the depth gauge to ~2N.
- AuditLog-017, CentralUI-037, ScriptAnalysis-009, SiteRuntime-033 (Low): a
  test-coverage gap plus stale doc-comments/spec following the remediation.

Header commit/date bumped to 1f9de8a2 / 2026-06-24 on all 17 modules; README
regenerated (8 pending / 576 total).

code-reviews/ConfigurationDatabase/findings.md

@@ -5,9 +5,9 @@
 | Module | `src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase` |
 | Design doc | `docs/requirements/Component-ConfigurationDatabase.md` |
 | Status | Reviewed |
-| Last reviewed | 2026-06-19 |
+| Last reviewed | 2026-06-24 |
 | Reviewer | claude-agent |
-| Commit reviewed | `d6ead8ae` |
+| Commit reviewed | `1f9de8a2` |
 | Open findings | 0 |
 
 ## Summary
@@ -1461,3 +1461,26 @@ Deferred (2026-06-19): the migrations are standard idempotent `ALTER`/guarded-`C
 verified by the model snapshot and the build, and `AddSmsNotifications` was applied to the real
 docker MS SQL during the feature's integration pass. A live-SQL migration test is tracked for a
 future ConfigurationDatabase test-stability pass.
+
+## Re-review — 2026-06-24 (commit `1f9de8a2`)
+
+Focused re-review of the changes since the prior review — verifying the code-review remediation + feature fixes are sound and regression-free. Reviewed by a per-module workflow agent; findings code-verified by the orchestrator.
+
+**Changes reviewed:** A single change to GetCurrentDeploymentStatusAsync in DeploymentManagerRepository.cs: added .ThenByDescending(d => d.Id) as a secondary sort key after .OrderByDescending(d => d.DeployedAt), plus an explanatory DeploymentManager-026 comment. This makes the "current" deployment-record read deterministic when two insert-only records for the same instance tie on DeployedAt within one clock tick.
+
+**Verdict:** The change is a small, correct, well-targeted fix that removes a real non-determinism in the read path. Because deployments are insert-only and DeploymentRecord.Id is the EF auto-increment identity PK (HasKey(d => d.Id), no ValueGeneratedNever), a later insert always carries a strictly higher Id, so ThenByDescending(d => d.Id) correctly selects the most recently inserted record on a DeployedAt tie. The fix matters for correctness: the sole caller TryReconcileWithSiteAsync branches on prior.Status (InProgress / timed-out Failed) in ShouldQuerySiteBeforeRedeploy, so reading the wrong tied record could alter reconciliation behavior. The change is regression-free (a read-only ordering refinement that is a no-op when DeployedAt differs), the InstanceId filter is index-backed, and both a repository-level test and a SiteRuntime regression test cover the exact same-tick scenario. No new issues introduced.
+
+| # | Category | Examined | Notes |
+|---|----------|----------|-------|
+| 1 | Correctness & logic bugs | ☑ | ThenByDescending(d => d.Id) is a valid deterministic tiebreaker; Id is auto-increment identity PK so highest Id == most recent insert. Resolves the same-DeployedAt ambiguity correctly. No issues found. |
+| 2 | Akka.NET conventions | ☑ | Pure EF repository read; no actor/messaging code involved. N/A to this change. No issues found. |
+| 3 | Concurrency & thread safety | ☑ | Stateless repository read over scoped DbContext; the change addresses a concurrency-induced tie (rapid redeploy / timed-out attempt) deterministically. No shared mutable state. No issues found. |
+| 4 | Error handling & resilience | ☑ | No new error paths; FirstOrDefaultAsync nullable result preserved and handled by caller (prior == null guard). No issues found. |
+| 5 | Security | ☑ | No secrets, no user input, fully parameterized LINQ-to-SQL. No injection or redaction surface. No issues found. |
+| 6 | Performance & resource management | ☑ | InstanceId is indexed (HasIndex line 41); secondary integer sort on an already-filtered set is negligible. No extra round-trips or allocations. No issues found. |
+| 7 | Design-document adherence | ☑ | Supports optimistic-concurrency/insert-only deployment-record model; DeploymentManager-026 is an inline decision tag consistent with existing CD-017/WP-4/WP-8 convention. No spec drift. No issues found. |
+| 8 | Code organization & conventions | ☑ | Matches surrounding style; sibling list methods (GetAll/GetByInstance) lack the same tiebreaker but their consumers do not depend on single-row determinism — not a defect. No issues found. |
+| 9 | Testing coverage | ☑ | RepositoryCoverageTests adds GetCurrentDeploymentStatus_SameTickRecords_DeterministicTiebreakerPicksHighestId; SiteRuntime adds SR029 regression test. Exact scenario covered. No issues found. |
+| 10 | Documentation & comments | ☑ | Inline comment accurately explains the tie scenario, the SQL Server undefined-ordering risk, and the chosen resolution. Accurate and proportionate. No issues found. |
+
+_No new findings — the changes in this module are clean._