perf(memory): per-AggOp memory profile tool + worst-offender report

[petrpan26]

The Phase 12.9 CI tripwire at crates/beava-core/tests/per_entity_size_dump.rs enforces size_of::<AggOp>() ≤ 80 B — but that only measures the stack-inlined slot. Variants that box state (Box<UDDSketch>, Box<TrendResidualState>, etc.) still cost 80 B inline PLUS unbounded heap. The static bytes_per_entity_p99 = 7000 placeholder in /metrics (crates/beava-server/src/http_admin.rs:124) is a guess; we don't actually know which ops dominate.

Build a per-op profiler that takes a populated AggOp variant and returns:

• stack_bytes — always 80 (the enum slot)
• heap_bytes — recursive into Box / Vec / HashMap / sketch internals
• breakdown — structured per data-structure-type within state (so we can see "Sum spends N bytes on Box<WindowedOp> overhead, UDDSketch spends X bytes on bucket map, EWMA spends Y bytes on Welford triple")

Run it against the fraud-team workload (the realistic 14-op / 110-feature mix per fraud-team.json config) at steady state and emit a sorted table.

Suspected offenders to verify

• sum, mean, count — small state, but each may pay an outsized Box pointer overhead relative to useful bytes. Specific concern that motivated this issue.
• Sketches (UDDSketch, HLL, count-min, bloom) — known-heavy but with workload-dependent variance.
• Windowed wrappers — every windowed op adds a Vec of bucket states; the overhead amortizes badly for short windows.
• TrendResidual, BurstCount — already flagged in v0.1 deferrals for borderline boxing (would drop the AggOp floor 80→64 B if all heavy variants box out).

Done when

• A new binary at crates/beava-bench/src/bin/memprofile.rs runs the profile against the fraud-team config + writes memory-profile-fraud-team.md with the sorted op-by-op table.
• The top 5 memory offenders have a concrete byte breakdown + a one-line recommendation per op (keep / box smaller / restructure).
• An assertion verifies Σ per-op heap bytes ≈ /metrics bytes_per_entity_p99 so reality and the Prometheus value stay coherent (separate bug if they diverge).

Sibling work this unlocks

Replacing the static bytes_per_entity_p99 placeholder with live dynamic sampling (the Phase 12.8 D-04 deferral) becomes trivial once this profiler is built — file separately after this lands and points at what to instrument.

~250 LOC + the generated report. Cohort Track-1 sized — meaty perf measurement work, no architectural decisions, plays directly to the pointer-overhead accounting question.

[petrpan26]

Investigation paths

Starter directions for whoever picks this up. Pick 1-2 to drive deepest; the others surface naturally from the profile output.

1. Custom MemUsage trait per state struct (S/M — the foundation)
A MemUsage trait implemented per AggOp variant + per state struct that returns (stack_bytes, heap_bytes, breakdown). Without this, you can't tell Box<HashMap> allocator overhead apart from useful state. Every other path on this list builds on it. Reference: dhat-rs integration or hand-rolled per-type accounting. Hand-rolled wins because it's deterministic across allocator + platform.

2. Drop AggOp inline floor 80→64 B by boxing TrendResidual + BurstCount (S — known win)
Already noted as a borderline-boxing candidate for TrendResidual + BurstCount (would drop the AggOp floor 80→64 B). Concrete S-sized issue once #68's profiler quantifies the per-entity savings. If 70% of features are non-TrendResidual/BurstCount, that's a 20% per-entity bytes win for those slots.

3. Field-name interning (M — likely big win)
Event row state uses SmallVec<[(CompactString, Value); 8]> (agg_state.rs). Per N entities × M features, that's N×M copies of the same field name strings. Replace with registry-time u8 field index → (field_idx: u8, value: Value). Wire format unaffected (registration-time mapping table). Likely 10-30% per-entity savings on feature-heavy workloads like fraud-team. Pairs with Phase 19.2 D-01 "Field pre-extraction" already on the ROADMAP.

4. Adaptive sketch precision (sparse → dense) (M-L — biggest sketch win)
HLL at default precision is ~6 KB; UDDSketch ~4 KB. Most entities have low cardinality and would fit in sparse mode (~100 B). Detect threshold per-entity and switch representations on cardinality crossing. HLL++ already supports this pattern; UDDSketch needs custom sparse-bucket implementation. Quantify the win first via #68's profile — if sketch-heavy ops dominate, this is the biggest single lever.

5. Per-entity storage shape: Vec<AggOp> vs HashMap<FeatureName, AggOp> (S to verify, M to migrate if needed)
If features are stored by registry-order index (deterministic at register time) instead of by name, you drop the HashMap overhead entirely. Confirm current shape in agg_state_table.rs first — likely already Vec for the hot path, but verify and document. If a HashMap lives anywhere on the per-entity path, that's a profile finding worth surfacing.

6. Lazy windowed bucket materialization audit (S — mostly verification)
Phase 19.1's lazy-bucket lift should mean windowed ops only allocate buckets that receive events. Verify on a windowed-heavy operator (rate_of_change, decayed_count, burst_count) — push a stream where 80% of buckets are empty, profile, confirm the empty buckets carry near-zero bytes. If the optimization regressed, that's the highest-leverage fix.

Each path is independently shippable. #68's profiler is the prerequisite for all of them — once it lands and the worst offenders are quantified, file the wins as separate issues sized by what the report identifies.