[Perf][Tooling] MemoryTracker's dormant allocation tracking measures the wrong thing

Problem

MemoryTracker.h uses Linux RSS (resident set size) as its memory signal; its allocation
manager registration is dormant/unused, and its max_bytes_used field accumulates total bytes
allocated over time rather than tracking peak live (currently-allocated) bytes. RSS is not
evidence of reduced allocation churn -- a change that reduces allocation count/rate can leave RSS
unchanged, and vice versa.

Recommendation

Separate RSS/working-set/private-byte telemetry (what the OS reports) from actual allocation
count, total bytes allocated, and peak live allocated bytes (what the allocator itself would
report if properly hooked up). Fix max_bytes_used's semantics (peak live, not cumulative) before
enabling/relying on the dormant tracker for any performance claim.

Acceptance criteria

• MemoryTracker's allocation-count/bytes-allocated metrics are distinct from RSS/working-set
  metrics in its reporting.
• max_bytes_used (or its corrected equivalent) reports peak live allocation, not a cumulative
  total.

Additional Context

From #843's Phase 0 tooling-trust review addendum ("Concrete performance-tooling work" table,
MemoryTracker row).

Start by reading MemoryTracker.h and the allocation-manager registration and reporting paths it contains. Review the MemoryTracker row in #843's Phase 0 tooling-trust addendum for context. The work is done when allocation count, total allocated bytes, peak live bytes, and RSS or working-set metrics are reported distinctly, with max_bytes_used representing peak live allocation.