docs: record lock vs lock-free decoder A/B — 3-4.5x under concurrent decode

Same-JVM interleaved comparison against the resurrected spin-lock
implementation: single-threaded parity (the uncontended lock was ~free),
but 8 threads sharing one decoder run 3.0-4.5x faster lock-free — the
spin lock serialized the concurrent hit path just like the old global
PoolRequests lock did.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018saXqYfAa3RvSJoDXK591R

quartz/plans/2026-07-02-nostrclient-receiver-perf.md

@@ -508,6 +508,13 @@ threads (80k duplicate-heavy frames, capacity 256 so rotations fire
 constantly) and asserts zero wrong messages with exact counter accounting;
 the benchmark assertion still holds post-refactor.
 
+Same-JVM A/B against the resurrected spin-lock implementation (3 rounds,
+interleaved): **1 thread — parity** (0.79–1.02×, noise around 1.0; the
+uncontended lock was already ~free), **8 threads sharing one decoder —
+lock-free wins 3.0–4.5×** (e.g. 127ms → 28ms for 128k frames). The lock was
+serializing the concurrent hit path exactly the way the old global
+PoolRequests lock did; ConcurrentHashMap removes it.
+
 ### Bounded per-connection receive buffer (REVERTED — deliberate design choice)
 
 A 4096-frame bound on the reader→consumer channel was tried (backpressure