feat(bench): add AggOp memory profiler

[tristanle22]

Summary

Adds a memprofile bench binary for profiling per-AggOp structural memory usage against the workloads. This is the first part of #68, which enables further analysis.

Linked issues

Related to #68

---

What changed

This PR adds a memprofile bench binary that profiles structural memory usage for each AggOp in the fraud workload. It introduces reusable MemUsage / MemProfile accounting in beava-core, generates a ranked Markdown report of per-op stack and heap estimates, and highlights the largest memory contributors.

Verification

Paste the summary block from bash .github/scripts/check.sh here so the
reviewer can see the local run passed:

PASS  cargo fmt --all --check  (0s)
PASS  cargo clippy --workspace --all-targets --features testing -- -D warnings  (1s)
PASS  cargo test --workspace --features testing  (22s)
PASS  ruff check python/  (0s)
PASS  mypy --strict beava/
PASS  pytest python (v0 acceptance suite)  (16s)

---

Pre-flight checklist

• bash .github/scripts/check.sh exits 0 (or each step passes manually)
• Verification block above replaced with real output
• Docs updated (docs/*.md, beava-website/project/docs/, decorator docstrings) if user-visible behavior changed
• No stale repository URLs (canonical: beava-dev/beava)
• If this commits a schema change to beava-website/deploy/site-metrics-pipeline.json, called out in this PR body — the deploy workflow re-registers with force=true, which silently lands destructive edits

[tristanle22]

2 concrete findings from memprofile

1. Boxing large AggOp payloads can cut the inline enum slot from 80B to ~40B

Today every feature stores an AggOp enum slot inline. That slot is sized by the largest remaining inline variant, not by the specific op stored in that row.

Current state:

size_of::<AggOp>() = 80B
largest inline payload = TrendResidualState at 72B
If we box all AggOp variants with payloads >= 40B, the largest remaining inline payload should be <= 32B, which should drop the enum slot to roughly:

80B -> 40B

That halves the per-feature inline stack footprint for every entity-feature row, even for small ops like count, sum, min, etc.

2. CountDistinct has a large mid-cardinality memory cliff

Current CountDistinct modes look roughly like this:

ExactArray <=16:     ~128B heap for Vec<u64> capacity
HashSet @1024 today: ~18.4KB
HLL dense:           ~4.0KB heap

The expensive case is the middle one. Once an entity crosses 16 distinct values, we allocate a hashbrown HashSet sized for the hash threshold. In the current profile that becomes:

requested capacity:          1024
hashbrown usable capacity:   1792
backing buckets:             2048
allocation_size:             ~18.4KB

The rounding happens because hashbrown targets about a 7/8 load factor:

needed buckets = ceil(1024 * 8 / 7) = ~1171
rounded buckets = 2048
usable capacity = 2048 * 7 / 8 = 1792
unused headroom = 1792 - 1024 = 768 entries

So mid-cardinality entities pay for far more exact capacity than they can use before promotion.
A better shape is tiered HashSet growth aligned to hashbrown capacity bands:

ExactArray <=16:     ~128B heap for Vec<u64> capacity
HashSet @224 tier:   ~2.3KB if we add that tier
HashSet @448 tier:   ~4.6KB
HashSet @896 tier:   ~9.2KB
HLL dense:           ~4.0KB heap

Suggested thresholds:

HASH_TIERS = [224, 448, 896]

Proposed mode shape:

0..16      ExactArray
17..224    small HashSet
225..448   medium HashSet
449..896   large HashSet
897+       HLL

This removes the big 17-value allocation cliff and avoids the 2048-bucket jump entirely. Mid-cardinality entities keep exact counts, but only pay for the tier they actually need. Throughput needs to be examined, as more allocations will be required

[ltungv]

i think this should be core::mem::size_of_val(core::mem::discriminant(self))

[ltungv]

should enum_slot_bytes = 0 and payload_bytes = 0?

[ltungv]

setting stack_bytes = enum_slot_bytes seems wrong

[ltungv]

i think this should be self.stack_bytes.saturating_sub(enum_slot_bytes).saturating_sub(payload_bytes)

[ltungv]

i think this should be MemProfile::new(aggop_label(self), size_of::<AggOp>())

[ltungv]

value_vec_breakdown relies on capacity() * size_of::<T>(). this can be wrong when it's applied to Vec<Value> since Value is an enum containing other heap-allocated objects

[ltungv]

same issue with value_vec_breakdown