docs(onnx-pack): the QDQ section's RSS figures, as this tree measures them

docs/onnx-pack.md

@@ -162,9 +162,12 @@ intermediate float tensor then never exists.
   a 256×1024×1024 case (262144 of 262144 values equal, so the int32-first arithmetic is in fact
   *more* exact than the CPU EP's float accumulation, which reaches the same function through two
   float tensors). Peak RSS growth of the run, measured around the run with the peak reset and
-  `malloc_trim` between the warm-up and the measurement: **~7000 kB for the CPU EP vs 264 kB fused**
-  on 256×1024×1024 (five runs: delta 6356, 6140, 6680, 6688, 6140 kB) — the 1 MB `x_dq` + 4 MB
-  `w_dq` + 1 MB `y` of float32 that no longer get allocated, plus the CPU EP's own arena churn.
+  `malloc_trim` between the warm-up and the measurement: the fused side is stable at **248-268 kB**,
+  the CPU EP side is **6.1-7.0 MB** on 256×1024×1024. Both are ranges on purpose — the CPU EP figure
+  is that process's arena growth, not a tensor size, so it moves run to run (eight runs on this tree:
+  6156, 6432, 6144, 6136, 6144, 6368, 7004, 6524 kB). What does not move is the bottom of that range:
+  6136 kB is the 1 MB `x_dq` + 4 MB `w_dq` + 1 MB `y` of float32 that no longer get allocated, and
+  what sits above it is the CPU EP's own arena churn.
   `ONEBIT_EP_QDQ=0` is the control: the same binary then claims the
   `MatMul` alone, logs a float `matmul` line, and the fused `qdq` line never appears.
 - **Works: per-axis scales, in the two forms the epilogue can fold.** `s_w[n]` (the weight's `axis 1`,