feat(grpc-events): handle-capture cycle — event-row gap proven NOT a client payload issue

Extends the instrument-grpc rewrite to log string (strHandle) + uint (uiHandle /
queryRequestType) params, not just byte[], and captures our SDK's live v8
openParameters for a byte-diff against the native.

Result of the exhaustive comparison (all live-confirmed via the opt-in
EventReadDiagnostic test):
- StartEventQuery request: byte-identical to the native (v6 layout)
- v8 OpenConnection openParameters: byte-identical to the native (302B) once
  ClientNodeName matches — every control byte/ConnectionType/token/ShardId
- handle usage identical: ExchangeKey->contextKey, registration->storage GUID
  (strHandle), query->client uint (uiHandle); handles valid (RTag/EnsT=True)
- queryRequestType=3, registration order, gzip metadata header — all match
- window has events (native returns 50 now); eventCount not it

Every observable client-side byte matches the native, yet the server scopes 0
events to our connection. The event RPCs succeed over our transport and return a
valid EMPTY result (not a transport error), so this is a connection/server-level
difference (session affinity tied to the native Grpc.Core HTTP/2 connection or a
connection identity used to scope events) — invisible to and unfixable by client
payload matching. Needs server-side insight, not more wire RE.

Added opt-in diagnostics (RegistrationDiag, LastResultBufferHex,
LastEventOpenRequestHex). 326/326 offline; gated test still pins the no-row throw.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B6mcaT2PjRFKcogzp9UkfC

docs/reverse-engineering/grpc-event-query-capture.md

@@ -300,6 +300,39 @@ implement `aahCryptV2` (RC4+MD5+prefix) managed-side, set the v8 token = that, a
 (non-destructive). The offline correlation data (one run's derived key + token + openParameters) is
 captured under `artifacts/.../` to validate the managed reproduction before going live.
 
+### Token implemented + auth WORKS live (2026-06-23); row retrieval still 0 — proven NOT a payload issue
+
+`token = RC4(password-UTF16LE, key = MD5(SHA256(ECDH secret)))` was implemented in pure managed C#
+(`HistorianNativeHandshake.BuildExchangeKeyCredentialToken` + `Rc4`; client key via
+`DeriveKeyFromHash(SHA256)`), golden-tested (RC4 standard vector + token construction), and
+**live-verified**: the v8 `OpenConnection` now **authenticates** against the 2023 R2 server (past the
+`132/171 AuthenticationFailed` wall). Auth is solved.
+
+The event **query** still returns `version-11 rowCount-0` while the native returns 50 for an
+**identical** request. Exhaustively ruled out as the cause (all confirmed live, opt-in
+`EventReadDiagnostic` test + the IL rewrite extended to log string/uint handle fields):
+
+- `StartEventQuery` request: **byte-identical** to the native (v6 layout)
+- v8 `OpenConnection` `openParameters`: **byte-identical** to the native (302 bytes) once ClientNodeName
+  is matched — every control byte, ConnectionType, token framing, ShardId, etc.
+- Handle usage: identical — `ExchangeKey`→contextKey, registration→storage-session GUID (`strHandle`),
+  query→client uint (`uiHandle`); our parsed handles are valid (registration `RTag/EnsT=True`, valid
+  `queryHandle`)
+- `queryRequestType = 3`, registration sequence/order, gzip metadata header — all match
+- window (events exist; native returns 50 *now*), eventCount — not it
+
+So **every observable client-side byte matches the native**, yet the server scopes 0 events to our
+connection. The event RPCs succeed over our transport and return a valid *empty* result (not a
+transport error), so it is **not a payload or transport-incompatibility issue** — it is a
+connection/server-level difference (e.g. session affinity tied to the native `Grpc.Core` HTTP/2
+connection or a connection-identity the server uses to scope events) that is **invisible to, and
+unfixable by, client payload matching.** Closing it needs server-side insight or a different angle
+(e.g. compare the full HTTP/2 connection setup / TLS identity), not more wire-payload RE.
+
+**Shipped this effort:** the complete ExchangeKey crypto (ECDH + SHA256 + MD5-keyed RC4 token) — the
+hard wall — pure managed, golden-tested, auth live-verified. Orchestrator stays on the no-row throw;
+gated test unchanged.
+
 **2 of 3 layers cleared** (key exchange + client key); the 3rd (token construction) is localized to a
 specific managed method, pending dnlib extraction. ExchangeKey + the v8 serializer are committed; the
 orchestrator stays on v6 (set `eventConnection: true` to re-arm once the token construction lands). The