compute: cache per-batch heap size in ArrangementSize operator

[antiguru]

Motivation

The arrangement-size logging operator (log_arrangement_size) is sometimes slow.
On every activation it recomputed the heap size of every live batch by walking each batch's backing regions, even when nothing changed and the operator fired for unrelated reasons.
For large arrangements this repeated walk dominates.

Description

Batches are immutable once sealed, so their heap size never changes after creation.
The operator already keys its batch map on Rc::as_ptr, relying on stable pointer identity.
This change caches the computed (size, capacity, allocations) tuple alongside the weak reference when a batch is first observed (via the input stream or map_batches), and only sums the cached values on subsequent activations.
Dead batches are still dropped, now via Weak::strong_count instead of an upgrade that cloned the Rc.

Per-activation cost drops from O(batches * columns * regions) to O(new batches * regions) plus an O(batches) sum, eliminating the repeated region walk.
Logged deltas are unchanged: because batches are immutable, the cached size equals what a re-walk would produce.

Verification

Behavior-preserving change covered by existing arrangement-size logging tests and the mz_arrangement_sizes introspection views.
cargo clippy -p mz-compute and cargo fmt are clean.

🤖 Generated with Claude Code

[petrosagg]

nice!