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/SiteEventLogging/findings.md

@@ -5,9 +5,9 @@
 | Module | `src/ZB.MOM.WW.ScadaBridge.SiteEventLogging` |
 | Design doc | `docs/requirements/Component-SiteEventLogging.md` |
 | Status | Reviewed |
-| Last reviewed | 2026-06-20 |
+| Last reviewed | 2026-06-24 |
 | Reviewer | claude-agent |
-| Commit reviewed | `4307c381` |
+| Commit reviewed | `1f9de8a2` |
 | Open findings | 0 |
 
 ## Summary
@@ -1436,3 +1436,26 @@ fail against the current code and pass once SiteEventLogging-024 is fixed.
 **Resolution**
 
 Resolved 2026-06-20 (commit `fd618cf1`): added `Query_FiltersByTimeRange_HandlesNonUtcOffset` — seeds known UTC instants, queries with a +05:00 offset, and asserts the returned row identities (not just count). Verified failing pre-fix, passing post-fix.
+
+## 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:** The diff normalises the `From`/`To` time-range bounds in `EventLogQueryService.ExecuteQuery` to UTC via `.ToUniversalTime()` before `ToString("o")` (lines 84, 92), with explanatory comments tagged SiteEventLogging-024 (re-opening -016). A matching regression test (`Query_FiltersByTimeRange_HandlesNonUtcOffset`) seeds three UTC rows and queries with `+05:00` bounds that bracket only the middle row, asserting on row identity.
+
+**Verdict:** The change is a correct, well-targeted bug fix. Stored timestamps are written by `SiteEventLogger` as `DateTimeOffset.UtcNow.ToString("o")` (always `+00:00`) and compared lexicographically under BINARY collation; the prior verbatim `ToString("o")` of a non-UTC `DateTimeOffset` emitted a different wall-clock value and `+05:00` suffix that sorted wrongly against stored `+00:00` rows, silently including/excluding the wrong events. `.ToUniversalTime()` normalises both the instant and the offset suffix to match stored values, aligning the code with the system-wide "all timestamps UTC" invariant and the doc's time-range filter requirement. The fix is regression-free (parameterised, no behavioural change for callers already passing UTC) and is backed by a focused test that genuinely fails on the unfixed code and passes after. No new issues found.
+
+| # | Category | Examined | Notes |
+|---|----------|----------|-------|
+| 1 | Correctness & logic bugs | ☑ | Fix correctly normalises both bounds to UTC; matches stored ISO-8601 +00:00 format and BINARY lexicographic comparison semantics. No off-by-one or boundary regression. |
+| 2 | Akka.NET conventions | ☑ | No actor code touched; query runs via lock-guarded WithConnection. No issues found. |
+| 3 | Concurrency & thread safety | ☑ | DateTimeOffset normalisation is pure/stateless; read still funnels through the recorder's write lock. No shared mutable state introduced. |
+| 4 | Error handling & resilience | ☑ | Existing try/catch returns a failed EventLogQueryResponse; the change adds no new throw paths (ToUniversalTime cannot throw on a valid DateTimeOffset). No issues found. |
+| 5 | Security | ☑ | Bounds remain bound as SqliteParameters; no injection surface change. No secrets in logs. No issues found. |
+| 6 | Performance & resource management | ☑ | Two extra in-memory conversions per query; negligible. No new allocations of concern, no resource leaks. |
+| 7 | Design-document adherence | ☑ | Aligns with CLAUDE.md 'all timestamps UTC' invariant and Component-SiteEventLogging time-range filter spec; no doc drift introduced. |
+| 8 | Code organization & conventions | ☑ | Consistent with existing parameter-binding style; comments accurately describe the stored format and the bug. No issues found. |
+| 9 | Testing coverage | ☑ | New test seeds UTC rows, queries with +05:00 bounds, asserts on row identity; genuinely fails pre-fix, passes post-fix. Good targeted coverage of the regression. |
+| 10 | Documentation & comments | ☑ | SiteEventLogging-024 comments correctly explain UTC ISO-8601 storage, BINARY lexicographic comparison, and the failure mode. Accurate and not stale. |
+
+_No new findings — the changes in this module are clean._