docs: write-spike results — write-reuse GREEN, ONE-KIND pool confirmed

docs/reverse-engineering/handshake-reuse-spike-results.md

@@ -98,3 +98,29 @@ streaming cursors) remains unproven and should be avoided by exclusive leasing.
 **Gate decision:** GREEN → HistorianGateway A1 Phase 1 (HistorianSession primitive + orchestrator
 acquire/execute split + re-vendor + leased-session pool with keepalive) is warranted and earns its
 own design + plan.
+
+---
+
+## 5. Write-spike addendum (Phase 1 Stage 0) — 2026-06-25
+
+Extends the harness to the write path via the `RunWriteOnSession` seam on
+`HistorianGrpcHistoricalWriteOrchestrator`. Read + bounded writes to `HISTORIAN_WRITE_SANDBOX_TAG`
+only.
+
+```
+reused-write[0] = 377 ms, ok=True
+reused-write[1] =  76 ms, ok=True       # 2nd write reuses the same 0x401 session — no handshake
+read-on-0x401 -> OK (rows=3)            # a WRITE-enabled session ALSO serves reads
+```
+
+**Findings:**
+- **Write-session reuse — GREEN.** Two historical writes on one reused `0x401` (write-enabled)
+  session both succeed; the 2nd skips the Create+handshake.
+- **One-kind pool — CONFIRMED.** A `0x401` session served a `StartQuery` read (`session.ClientHandle`)
+  successfully. So a single **write-enabled** session serves both reads and writes — the gateway pool
+  needs **one session kind**, not two. (`0x401` "unlocks write capability" and is a superset of the
+  `0x402` read-only mode, as the vendored comment hinted.)
+
+**Decision for Phase 1 Stage 3:** the gateway always opens `WriteEnabled` sessions; the
+`HistorianSessionPool` is a **single warm pool** (no per-kind keying). `HistorianSessionKind` still
+exists upstream for API clarity, but the gateway uses only `WriteEnabled`.