docs: reconcile the remaining performance claims with the corrected artifacts

Sweep of every public .md for bare throughput/latency figures. Most were already
handled correctly and are left alone: docs/METHODOLOGY.md and
docs/REPRODUCIBILITY_CHECKLIST.md list their claims under "not allowed" /
"reject", docs/PLATFORM_ARTIFACT_ROADMAP.md lists its under "Unsafe:", and
RELEASE_NOTES.md's Performance Highlights table already carries a withdrawal
note. Two things did not line up.

RELEASE_NOTES.md contradicted itself. "4.1M dec/s d=5" and "14.6M dec/s @ d=5,
batch=10000" were stated as plain fact in the decoder-status table and the GPU
section, while the *same* figures sat forty lines below under a header saying no
surviving artifact backs them and they must not be cited. Point both at that
note. The GPU path has not been re-measured under the circuit-level pipeline -
official_benchmark_results.* covers the CPU decoders, PyMatching and ldpc only -
so nothing is asserted in its place.

The README needed to say *which* Union-Find. The measured rows use the weighted
variant, which is what ler._dem_observable_decoder resolves;
docs/BENCHMARK_COMPETITIVE.md benchmarks the unweighted one and reports it
beating PyMatching on latency at d=3. Both are real and they do not conflict -
unweighted UF is faster because it discards the log((1-p)/p) weights, which is
also why that document records it above threshold from d=5 up. Stated explicitly
so the two documents cannot be read as contradicting each other, with the
instruction to quote speed and accuracy together or not at all.

Re-verified after editing: all 14 cited rows still match the CSV, no broken
relative links.

Author: qectorlab

README.md

@@ -454,12 +454,21 @@ Two findings, stated per-cell and not generalised (see
   returned *the same number of logical failures on the same 100,000 samples* —
   1891 and 1596 respectively, identical to the digit. On this workload the two
   agree exactly, which is a checkable claim rather than a rounded one.
-- **Throughput.** PyMatching was faster than every QECTOR decoder at every
-  distance measured here — roughly 3× at `d = 3` against `qector_unionfind`,
-  and two orders of magnitude against `qector_blossom` by `d = 11`. That is
-  consistent with the long-standing note elsewhere in this project that
-  PyMatching leads on plain MWPM. It is not a regression, and the artifacts do
-  not hide it.
+- **Throughput.** PyMatching was faster than every QECTOR decoder measured here,
+  at every distance — roughly 3× at `d = 3` against `qector_unionfind`, and two
+  orders of magnitude against `qector_blossom` by `d = 11`. That is consistent
+  with the long-standing note elsewhere in this project that PyMatching leads on
+  plain MWPM. It is not a regression, and the artifacts do not hide it.
+
+Note which Union-Find this is. `qector_unionfind` above is the **weighted**
+variant, which is what `ler._dem_observable_decoder` resolves and what the
+accuracy column reflects. `docs/BENCHMARK_COMPETITIVE.md` benchmarks the
+**unweighted** one (`qector_unionfind_unweighted`) and reports it beating
+PyMatching on latency at `d = 3` — both results are real, and they are not in
+conflict: unweighted UF is faster precisely because it discards the
+`log((1-p)/p)` edge weights, which is also why that document records it as
+above threshold at circuit level from `d = 5` upward. Speed and accuracy are
+being traded, so quote the two numbers together or neither.
 
 Neither finding generalises beyond the cells above. Regenerate on quiesced
 hardware, and state the noise model, before any number here is used in a claim.

RELEASE_NOTES.md

@@ -393,8 +393,8 @@ This release delivers the complete QECTOR v3 decoder suite with 4 algorithmic ba
 | `GNNPredecoder` | Experimental | Message-passing + edge readout, forward pass OK |
 | `LookupTableDecoder` | Stable | Exact d=3,5,7 precomputed, SIMD fallback |
 | `HybridDecoder` | Stable | Auto-selection per syndrome difficulty |
-| `StreamingDecoder` | Stable | Sliding window, 1.6 µs real-time |
-| `BatchDecoder` / `CPUBatchDecoder` | Stable | SIMD, parallel, pooled — 4.1M dec/s d=5 |
+| `StreamingDecoder` | Stable | Sliding window; latency figure withdrawn, see below |
+| `BatchDecoder` / `CPUBatchDecoder` | Stable | SIMD, parallel, pooled; throughput figure withdrawn, see below |
 | `OpenCLBatchDecoder` | Stable | GPU dual-kernel, transparent fallback, resilience |
 
 ### GPU Acceleration (OpenCL)
@@ -403,7 +403,11 @@ This release delivers the complete QECTOR v3 decoder suite with 4 algorithmic ba
 - Transparent CPU fallback on GPU failure
 - Auto-recovery: exits degraded mode after 10 successful calls
 - Observability: `consecutive_failures`, `total_failures`, `gpu_recoveries`, `degraded_calls`
-- Performance: 14.6M dec/s @ d=5, batch=10000
+- Performance: the "14.6M dec/s @ d=5, batch=10000" figure is **withdrawn** — it
+  is one of the rows under *Performance Highlights* below, which no surviving
+  artifact backs and which must not be cited. The GPU path has not been
+  re-measured under the circuit-level pipeline; `official_benchmark_results.*`
+  covers the CPU decoders, PyMatching and ldpc only.
 
 ### Production Infrastructure