[shinaoka]

Three changes, in dependency order.

1. Allocation counters on every arm

Every record now carries n_allocations and allocated_bytes for the timed
operation, median over the timed runs, from a GlobalAlloc wrapper in
src/alloc.rs. The counters expose the per-call overhead that the wall time
hides. Case 1 at input chi = 5:

arm	time (s)	allocation calls	allocated
naive	0.000918	5 323	2.61 MiB
zipup	0.006449	80 441	12.09 MiB
fit	0.012445	142 866	23.60 MiB
aci	0.051511	935 093	92.31 MiB

fit makes 27x the allocation calls of naive for the same result. Records
written before the counters omit both fields, and the report leaves their
columns blank, so the schema version stays at 1.

2. Move every tensor4all-rs pin to a515738

9e9aeda (2026-08-19) to a515738 (main, 2026-10-10). All nine crates move
together, and the revision also changes in scripts/run_all.sh and in the
TENSOR4ALL_REV cache-key constant of src/gaussian_input.rs, which the
Gaussian input cache keys on.

Two API migrations:

• tensor4all_partitionedtreetn::PatchingOptions.rtol became cutoff, with
  cutoff = old_rtol^2 (the new default 1e-24 is documented upstream as the
  behaviour-parity translation of the superseded rtol = 1e-12).
• Only the TreeTN variant was renamed. tensor4all_partitionedtt::PatchingOptions
  still takes rtol.

src/patched_mpo.rs squares the tolerance at the three TreeTN call sites, so
the truncation budget is unchanged. No other call site needed a change.

On this machine, case 1 at input chi = 5, against a local probe at the old
pin:

arm	9e9aeda	a515738
naive	0.001325	0.000918
zipup	0.026454	0.006449
fit	0.043044	0.012445
aci	0.032514	0.051511

3. Optional multithreaded sweep

BENCH_THREADS=n runs the same three cases on n Rayon, BLAS and tenferro
threads pinned to a contiguous core range, in its own <machine>-<n>t profile.
AGENTS.md and the README record that it is scaling evidence only: the
single-core profile stays the source of truth and the two are not merged.

Sweeps in this PR

result/linux-ryzen-ai-9-hx-470 and result/linux-ryzen-ai-9-hx-470-4t, both
from source revision 05ebd78 against tensor4all-rs a515738.

Machine: AMD Ryzen AI 9 HX 470 with Radeon 890M, 12 physical cores and 24
hardware threads, 58.5 GiB RAM, Linux. The one-thread sweep is pinned to CPU 0;
the four-thread sweep is pinned to CPUs 0-3, which lscpu -e reports as four
distinct physical cores on this part.

The four-thread profile scales only where the work is large. It is slower than
one thread below roughly 40 ms per case, and 1.5x to 1.7x faster at the largest
Gaussian instances: gaussian_mpo_contraction/global_fit/n=128 0.2022 s to
0.1195 s, gaussian_elementwise/patched_fit/n=128 0.4079 s to 0.2484 s,
gaussian_elementwise/global_fit/n=128 0.1537 s to 0.0980 s.

Validation

cargo fmt --all -- --check, cargo clippy --locked --all-targets -- -D warnings,
cargo test --release --locked (22 passed), and python3 scripts/report.py on
both profiles.

4. Lead the README to the results

There was no path from the README to a single number. The README now opens with
a Results table linking every committed profile's report.md, with the
machine, thread count and measured tensor4all-rs revision in the same row, and
result/README.md describes the layout of a profile directory and which
artifacts are generated.