Measure Arena block growth layouts

[helly25]

Adds a benchmark-only proof for Arena block-growth decisions. It keeps competing strategies out of the production API until clean measurements show which choices are worthwhile, and records both latency and memory cost for the same realistic workload.

This pull request is intentionally draft and must not merge before validated Apple M5 Pro and AMD Zen 5 JSON artifacts exist.

AG;DR

• Adds //mbo/memory:arena_layout_benchmark as a manual clang-tidy-covered benchmark target.
• Compares fixed 4 KiB, 1.5x, 2x, 4x, and listed 4/16/64/256/1024 KiB growth.
• Runs every strategy in both retained-block and fresh-arena lifecycle modes.
• Uses 16,384 deterministic string-like allocations per iteration.
• Injects a dedicated 64 KiB oversized request every 257 allocations, verifying that oversized traffic does not distort normal growth.
• Reports block count, reserved bytes, used bytes, and waste together with latency and throughput.
• Compares pointer, fixed contiguous offset, stable segmented offset, and fixed contiguous inline string records.
• Compares ordinary pointer/size records with separate pointer and size arrays to test whether removing AoS padding justifies an extra hot-path load.
• Measures insertion and sequential/permuted dense-ID lookup independently, and labels exact-reservation candidates as fixed-capacity so they cannot be mistaken for growing-container guarantees.
• Compares retain-all, release-all, bounded-small-block cache, and full-budget cache behavior after a burst, including backing blocks, cache metadata, peak bytes, retained bytes, and retained block count.
• Documents the proof target, its scope, and remaining retention/layout candidates in the memory measurement methodology.

Validation at head 5bd16d46c:

• optimized Clang 22 build of //mbo/memory:arena_layout_benchmark
• focused pre-commit hooks on all changed files
• complete short smoke execution of every candidate
• bazel test //mbo/memory:arena_test //mbo/memory:block_source_test after rebasing onto the GCC portability correction in PR 440

Apple M5 Pro evidence is now committed as four validated immutable JSON envelopes from clean benchmark commits c913ba9ae, 673d95295, and 8a82b50cb. The main layout artifact contains 22 families and exactly nine repetitions per family. Listed growth won both fresh and retained fastest-three timing while reserving only about 259 KiB more than fixed 4 KiB growth. For growing record layouts, pointers beat stable segmented offsets on sequential and permuted lookup by 34.7% and 22.7%, while segmented offsets reserved roughly 1.70 MiB versus 2.29 MiB. An isolated full-protocol insertion rerun found their all-nine means within 1.6% but remained noisy, so insertion does not decide the representation.

The full M5 retention artifact from clean 673d95295 confirms the bounded small-block cache: fastest-three 7.686 us with 652,926 bytes retained, versus 10.210 us and 6,418,558 bytes for retain-all, and 10.655 us with zero retained for release-all. It is within 0.5% of caching the full chain while retaining only 10.2% as many bytes. The artifact records all nine samples, memory counters, 72.77-second duration, and the higher 3.54/4.52/4.61 host-load context.

The full pointer-layout artifact confirms that SoA saves exactly 65,536 bytes, or 2.86% of total reserved memory, but slows fastest-three insertion by 19.6%, sequential lookup by 20.2%, and permuted lookup by 22.0%. The run ended at elevated load averages of 2.90/8.77/7.94; nevertheless, lookup CVs are below 0.82% and the observed penalties greatly exceed sample variation. The complete samples and load context remain in the JSON rather than being discarded. Pointer AoS remains the provisional growing representation pending Zen 5 and complete-interner measurements.

Still required:

• add any further serious metadata layout identified during review;
• run the clean randomized nine-repetition protocol on AMD Zen 5;
• commit and validate the Zen 5 immutable JSON envelopes;
• publish fastest-three-of-nine plus full distribution and memory comparisons;
• feed the selected behavior back into the production Arena PR without multiplying core implementations.

Portability: the proof and production code remain C++20-compatible. This PR introduces no user-facing API.