docs: neutral technical register for the GPU and benchmark sections

Rewrites the README findings and the CHANGELOG GPU entry as declarative
statements of what was measured, removing editorial framing.

Corrects a factual error introduced earlier in this cycle: the README asserted
that CUDABatchDecoder and OpenCLBatchDecoder take no edge_weights argument. They
accept one. Omitting it is a configuration choice that selects topology-only
cluster growth, which is what produces the above-threshold behaviour reported in
the same section - not an absent capability. The corrected text states both
configurations and their measured cost.

Author: qectorlab

CHANGELOG.md

@@ -20,11 +20,12 @@ reading the tree.
   the CPU backends — not from a separate harness. This produces the weighted-GPU
   logical error rate that the README previously recorded as unquotable for want
   of a surviving artifact.
-- **What the measurement says.** Unweighted GPU is fast and *above threshold*:
-  its LER stops improving as `d` grows (0.059 at `d = 5`, 0.048 at 9, 0.035 at
-  13), so scaling the code does not help it. Weighted GPU is below threshold —
-  0.026 → 0.010 → 0.007 over the same range — at roughly 32x the cost. Quote a
-  GPU throughput number together with its LER or not at all.
+- **Measured behaviour.** The unweighted configuration operates above threshold:
+  its logical error rate does not improve as `d` grows (0.059 at `d = 5`, 0.048
+  at 9, 0.035 at 13), so increasing code distance does not help it. The weighted
+  configuration is below threshold — 0.026 → 0.010 → 0.007 over the same range —
+  at roughly 32× the cost per shot. GPU throughput and GPU logical error rate
+  should be cited together.
 - **Weighted growth kernel: 1.40x–1.57x faster, bit-identical output.** Per round
   the weighted loop ran an O(n_checks) scan plus three O(E) sweeps for up to
   `E+N+2` rounds, and passes A and B each walked two parent chains per edge with
@@ -36,12 +37,13 @@ reading the tree.
   Verified by capturing every correction from the pre-change build across
   `d = 5/9/13` × 2048 shots and asserting byte-equality after: *bit-identical
   across 12 arrays*, with CUDA-vs-CPU agreement unchanged to the digit.
-- **Known and not hidden:** weighted GPU is *not* bit-identical to weighted CPU,
-  and diverges further with distance (67% → 14% → 0.24% shot agreement at
-  `d = 5/9/13`). The kernel grows in `f32` and `uf_core::grow_weighted` in `f64`,
-  so `dt` differences compound over thousands of rounds into different — often
-  equally valid — fusion orders. Pre-existing, unrelated to the optimisation
-  above, and stated here rather than left for a user to discover.
+- **Numerical divergence from the CPU path.** Weighted GPU output is not
+  bit-identical to weighted CPU, and the two diverge further with distance
+  (67% → 14% → 0.24% per-shot agreement at `d = 5/9/13`). The kernel grows in
+  `f32` and `uf_core::grow_weighted` in `f64`, so `dt` differences compound over
+  thousands of rounds into different — and frequently equally valid — fusion
+  orders. This behaviour pre-dates, and is unrelated to, the optimisation
+  described above.
 
 ### Benchmarks — corrected artifacts, and what they say
 - **`official_benchmark_results.{json,csv,md,pdf}` were regenerated.** The first

README.md

@@ -468,31 +468,35 @@ The full 137-row table — every shot count, plus the 73 cells that exceeded the
 per-cell budget and were therefore *not measured* — is in
 `official_benchmark_results.md`.
 
-Findings, stated per-cell and not generalised (see
-`docs/REPRODUCIBILITY_CHECKLIST.md`):
-
-- **`qector_blossom` matches PyMatching exactly.** At `d = 3` and `d = 5` both
-  returned the same number of logical failures on the same 100,000 samples —
-  1891 and 1596. Identical to the digit, which is a checkable claim.
-- **PyMatching leads on throughput at every distance measured**, consistent
-  with the long-standing note elsewhere in this project that it leads on plain
-  MWPM. Not a regression, and not hidden.
-- **The GPU kernels are fast and above threshold.** `qector_cuda` reaches
-  1.29M dec/s at `d = 3`, but its LER *stops improving with distance*: 0.061 at
-  `d = 5`, 0.043 at `d = 7`, 0.038 at `d = 15`, against PyMatching's 0.016 →
-  0.012 → 0.0031 over the same range. A decoder whose logical error rate
-  plateaus while `d` grows is above threshold — scaling the code does not help
-  it. The cause is not the kernel: `CUDABatchDecoder`/`OpenCLBatchDecoder` take
-  `(check_to_qubits, n_qubits)` and no `edge_weights`, so they decode
-  topology-only. `docs/BENCHMARK_COMPETITIVE.md` records the same effect for
-  unweighted Union-Find on CPU. Weighted UF (UF-01) exists in the Rust core and
-  is the path to closing it.
-- CUDA and OpenCL returned identical logical-failure counts wherever both ran
-  the same cell, consistent with the bit-identity claim made elsewhere.
-
-**Do not quote a GPU throughput figure without its LER.** The two GPU columns
-above are the reason: on speed alone they look like the headline result, and on
-accuracy they are not yet usable for scaling a surface code.
+Findings apply to the cells listed above and are not generalised beyond them
+(see `docs/REPRODUCIBILITY_CHECKLIST.md`).
+
+**Accuracy parity with PyMatching.** At `d = 3` and `d = 5`, `qector_blossom`
+and PyMatching 2 recorded identical logical-failure counts on identical sample
+sets — 1891 and 1596 in 100,000 shots respectively.
+
+**Throughput.** PyMatching 2 leads at every distance measured here. This is
+consistent with the position recorded elsewhere in this project that PyMatching
+leads on plain MWPM.
+
+**GPU accuracy depends on whether matching weights are supplied.**
+`CUDABatchDecoder` and `OpenCLBatchDecoder` accept an optional `edge_weights`
+argument. Omitting it selects topology-only cluster growth, and the resulting
+logical error rate does not improve with code distance — 0.061 at `d = 5`,
+0.043 at `d = 7`, 0.038 at `d = 15` — which is the signature of operation above
+threshold. Supplying the DEM's `log((1-p)/p)` weights restores distance
+scaling: 0.026 at `d = 5`, 0.010 at `d = 9`, 0.007 at `d = 13`. The weighted
+path costs roughly 32× the throughput of the unweighted one.
+`docs/BENCHMARK_COMPETITIVE.md` records the same effect for unweighted
+Union-Find on CPU. See the quick-start above for the weighted construction.
+
+**Backend agreement.** CUDA and OpenCL returned identical logical-failure counts
+in every cell where both ran, consistent with the bit-identity property recorded
+elsewhere in this project.
+
+GPU throughput and GPU logical error rate should be cited together. The
+unweighted configuration is the fastest column in the table and simultaneously
+the least accurate; either figure alone misrepresents it.
 
 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.