Track latest tensor4all-rs (ae655a9), expand default sweeps, add the mac-m1-8gb profile

[lingrui96]

What this does

• Moves the pin from 7cfec22 to ae655a9, the current origin/main tip of tensor4all-rs, whose one new commit is tensor4all-rs#575 (treetci early stop on max_bond_dim saturation).
• Expands the default sweeps: cases 2 and 3 now run BENCH_RS=6,8,10,12,14, case 1 adds K=128. A full run_all.sh takes about 8 minutes on the machine below, on an otherwise idle machine.
• Splits result profiles per machine: your result/mac-cpu sweep stays exactly as you committed it, and the new numbers land in result/mac-m1-8gb (an 8 GB Apple M1 MacBook Pro). Nothing of yours is overwritten, and README's Latest results section lists both profiles with their pins.
• run.yaml now records chip and memory, and no longer records the hostname: on a public repository a DHCP name leaks the operator's institution and location over time. The branch history was rebuilt once before review for the same reason. Your historical run.yaml files on main are untouched, that is your call.
• Refreshes every quoted number in the README and the runner doc comments from the mac-m1-8gb sweep, and adds known issue 9: the naive arms at r >= 10 are memory bound on 8 GB, so their wall times are only comparable within one profile and official sweeps want an idle machine.

Review follow-ups

All four requested cleanups are in, no rerun needed:

1. Title updated to name the mac-m1-8gb profile instead of a mac-cpu rerun.
2. Duration reconciled to about 8 minutes. The 14 minute figure was measured before a reboot, on a machine deep in swap; the committed sweep took 7.8 minutes from the first raw record to the rendered reports, which is what the README says.
3. The provisional AGENTS.md Pushing section is removed. It can return as accepted maintainer policy in its own change.
4. The spec's status is now implemented, and its open question list is replaced by your answers, so it reads as a record.

Thank you for the answers on the open questions. Recorded in the spec, and the construction benchmark, option (a), is the direction for the next case.

🤖 Generated with Claude Code

[shinaoka]

Thanks for the thorough update. I checked the branch locally:

• cargo test --release: 19 passed
• smoke runs for all three binaries: passed
• all 64 raw JSON files parse successfully
• the Markdown reports reproduce exactly from the committed raw data
• the tensor4all-rs pin ae655a9 matches the current upstream main

The benchmark and generated results look sound. I recommend merging after four small documentation/governance fixes; no rerun is needed:

1. Update the PR title: it says rerun mac-cpu, but this PR adds the mac-m1-8gb profile.
2. Reconcile the full-run duration: the PR body says about 14 minutes, while the README says roughly 8 minutes.
3. Remove the provisional AGENTS.md Pushing section from this PR, or replace it only after the maintainer has explicitly accepted the policy. AGENTS.md should contain active instructions, not a proposal awaiting veto.
4. Remove the internal design spec or change its stale pending execution status to implemented.

My recommendations on the open questions:

• Next case: benchmark TCI/quantics construction first, since #575 directly changes that path and the existing cases exclude construction time.
• #571 remains open with no assignee or milestone; keep the simplett fit arm excluded.
• I found no public issue or plan for a simplett tensor-train elementwise product; track it separately only when it blocks planned work.
• Keep mac-m1-8gb as a machine-specific profile, but do not use its memory-bound naive timings as the cross-machine headline.
• threads: default is acceptable for this profile. For a future official cross-machine sweep, pin a numeric thread count.
• Keep BENCH_BOX_L=6 for now. If higher-accuracy comparisons are needed, use a finite-box analytic reference rather than only enlarging the box at fixed R.
• The per-machine profiles, chip/memory fields, and hostname removal are good.
• The proposed branch/PR/human-merge policy is reasonable, but should be added as an accepted maintainer policy in a separate change.

With those small cleanups, this is ready to approve.