TD-T22: tighten the "zero scalar ALU" claim to what was actually measured

Self-caught overclaim in the previous commit. I wrote "0 scalar ALU" from a
narrow grep for `(add|sub|xor|rol|ror|shl|shr|or|and)[lqwb]`. A broad sweep
of ALL non-vector instructions across the three probe symbols returns:

  3 retq   1 movl   1 jne   1 decl

The `decl` IS a scalar ALU instruction — it decrements the `arx_ten_rounds`
loop trip count. So "zero scalar ALU instructions" is literally false.

The claim that survives, and the one the finding actually rests on: **no
scalar operation touches lane data.** Every u32 lane op in all three probes
is a packed AVX2 instruction; the only scalar work is loop control.

Corrected in both sites and stated explicitly in the artifact, since a
knowledge doc that overstates its own measurement is the failure mode this
investigation exists to document.

Author: claude

.claude/knowledge/agnostic-surface-cpu-matrix.md

@@ -102,8 +102,10 @@ than real `__m256i` intrinsics. Needs verification (see § J integration plan).
 > the answer is: the storage IS scalar in the SOURCE, and that costs nothing.
 > `.cargo/config.toml` pins `-Ctarget-cpu=x86-64-v3` for every x86_64 build,
 > so LLVM auto-vectorizes the `avx2_int_type!` loop bodies into packed AVX2.
-> Measured on the ChaCha20 ARX triple over `U32x16`: **zero scalar ALU
-> instructions**, `rotate_left(16)` strength-reduced to `vpshufb`, and the
+> Measured on the ChaCha20 ARX triple over `U32x16`: **no scalar arithmetic
+> touches lane data** (the only non-vector ops across all three probes are
+> `retq` and the loop's `movl`/`decl`/`jne` trip counter),
+> `rotate_left(16)` strength-reduced to `vpshufb`, and the
 > 10-round double-round loop emits exactly **8 `vpaddd` for 64 u32 lanes** —
 > the AVX2 instruction-count floor, with no headroom a hand-written
 > `__m256i` version could recover. `reduce_sum` emits a logarithmic

.claude/knowledge/td-t22-asm-investigation.md

@@ -83,7 +83,7 @@ cargo rustc --release --example td_t22_probe -p ndarray -- --emit asm -C debugin
 | `vpxor` | 2 |
 | `vpshufb` | 2 |
 | `vmovdqa` | 5 |
-| **scalar ALU** | **0** |
+| **scalar arithmetic on lane data** | **0** |
 
 16 u32 lanes = 2 ymm registers, so 2 packed ops per lane-op is exactly one
 instruction per half. LLVM strength-reduced `rotate_left(16)` into a **byte
@@ -99,7 +99,7 @@ intrinsic version would emit.
 | `vpshufb` | 6 |
 | `vpsrld` / `vpslld` / `vpor` | 4 / 4 / 4 |
 | `jne` | 1 |
-| **scalar ALU** | **0** |
+| **scalar arithmetic on lane data** | **0** |
 
 The `jne` shows this is one rolled loop body, so the counts are per
 iteration. **This is the instruction-count floor:** 4 `U32x16` adds = 64 u32
@@ -116,11 +116,20 @@ for a hand-written version to recover.**
 | `vpshufd` | 2 |
 | `vextracti128` | 1 |
 | `vmovd` | 1 |
-| **scalar ALU** | **0** |
+| **scalar arithmetic on lane data** | **0** |
 
 A textbook logarithmic horizontal-reduction tree, not the scalar
 `wrapping_add` fold the source literally spells out.
 
+**Precision on "0 scalar arithmetic on lane data".** A broad sweep of ALL
+non-vector instructions across the three symbols returns exactly:
+`3 retq`, `1 movl`, `1 jne`, `1 decl`. The `movl`/`decl`/`jne` are the
+`arx_ten_rounds` loop counter and branch — loop control, not lane
+arithmetic. So the honest claim is **no scalar op touches lane data**, not
+"no scalar instruction exists": one `decl` does, and it decrements the trip
+count. Every `u32` lane operation in all three probes is a packed AVX2
+instruction.
+
 ## The same result holds for the float side
 
 `F32x16::mul_add` (`simd_avx2.rs`) is likewise written as