docs(c2): record 2020-vs-2023R2 positive control for the event-read server gate

Adds the positive control that the prior C2 evidence lacked. The SAME native WCF
event-read client returns real events (5) from a local AVEVA Historian 2020 but 0
from the 2023 R2 server over the identical sequence and window, while both boxes
hold tens of thousands of events in SQL — isolating the zero-rows to the 2023 R2
server, not the client, protocol, or serializers.

- wcf-event-read-spike-results.md: new "2026-06-26 positive control" section
  (2020 vs 2023 R2 A/B from one WCF client; stock-2020-client version-self-block
  caveat; stock-2023R2 gRPC cross-check).
- grpc-event-query-capture.md: re-control note — the 2026-06-22 stock 50-row
  capture did NOT reproduce; the stock 2023 R2 client now also returns 0 rows.
- HistorianGrpcIntegrationTests: correct the stale "capture-gated, NOT
  server-gated" comment to the server-gate conclusion backed by the controls.

Sanitized throughout (counts, native return codes, buffer lengths only).

Claude-Session: https://claude.ai/code/session_012SDSQ3AcaXqPcBtDESBRii

docs/reverse-engineering/wcf-event-read-spike-results.md

@@ -73,3 +73,33 @@ connection) — not client-fixable. **C2 stays closed won't-fix**, for this (cor
 - The C2 spike is now transport-selectable (integrated|certificate), cross-platform for the cert
   transport, bounded (per-call timeout + overall budget with a phase-diagnostic dump), and version-gate
   bypassable. Output stays sanitized (counts, native return codes, buffer lengths, sha256).
+
+## 2026-06-26 — positive control: same WCF client, 2020 historian vs 2023 R2
+
+The earlier evidence triangulated the gate but lacked a clean *positive* control — proof that the
+native event-query path returns rows for **some** historian, so that the 0-row 2023 R2 result can be
+attributed to the server rather than to the client/protocol. This run supplies it, A/B against two
+historians from the **same** WCF event-read client (`HistorianWcfEventOrchestrator`, whose wire
+protocol is byte-replayed from stock 2020 captures), same 365-day window:
+
+| target historian | transport | RegisterTags (RTag2) | result buffer | events |
+|---|---|---|---|---|
+| **local AVEVA Historian 2020** | WCF, integrated | **0 — success** | terminal after rows | **5** |
+| **2023 R2** (the C2 server) | WCF, certificate | (gate, as documented) | 10-byte 0-row header → long-poll | **0** |
+
+SQL ground truth (`Runtime.dbo.Events`) for the same two boxes: the 2020 historian holds ~51.6k events
+over the window, the 2023 R2 holds ~71.5k — both populated. So the **identical native WCF event-read
+client returns real events from a 2020 historian and zero from the 2023 R2 server**. That isolates the
+zero-rows to the 2023 R2 server: not the client, not the protocol, not our serializers.
+
+Notes / honesty caveats:
+- The genuinely-**stock** 2020 client (`aahClientManaged.dll` v2020.0406.2652.2, driven by reflection)
+  could **not** be run end-to-end here: against the local 2020 historian (services patched to build
+  3383.3) it self-blocks at `StartEventQuery` with `Invalid InterfaceVersion` (242) — a client-side
+  build/version gate, and the stock client has no version-bypass. Our client (which *does* bypass the
+  version check and byte-replays the same native sequence) is the faithful proxy that reaches the rows.
+- Cross-check on the gRPC leg the same day: the **stock 2023 R2** client (native Event connection, its
+  own correct event query) returned **0 rows** over 30d/90d/365d/3yr against the 2023 R2 server; the
+  2026-06-22 "50 rows" stock capture did not reproduce. Same server-gate, both transports, both clients.
+- Output sanitized throughout (counts, native return codes, buffer lengths only — no event identity,
+  host, or credentials).