fix(memory): reclaim MLX pool before hot-cache shrink - #2635

Summary

• request a synchronized MLX buffer-pool reclaim before destructive hard-pressure enforcement
• defer hot-cache shrink, eviction, and request abort for at most five polls, and only when a scheduler accepted the reclaim request
• preserve immediate enforcement for emergency pressure, disabled reclaim, small or unreadable pools, missing schedulers, reclaim-request failures, and exhausted grace
• keep the existing per-tick store-cache concurrency adjustment active during the grace

Root cause

ProcessMemoryEnforcer compares a process footprint that includes MLX's reclaimable buffer pool against its watermarks. At hard pressure it previously sized and performed hot-cache shrink before asking the scheduler to clear that much larger pool. When pooled buffers dominated the footprint, the computed hot-cache target repeatedly fell to zero even though a synchronized pool clear could recover the pressure without destroying reusable prompt state.

The reclaim remains scheduler-owned: this change only sets the existing pressure-reclaim flag, and the actual Metal clear still runs at the synchronized inference-step boundary.

Validation

• uv run pytest -q tests/test_process_memory_enforcer.py: 163 passed
• uv run pytest -q tests/test_process_memory_enforcer.py tests/test_scheduler.py tests/test_hot_cache.py -m 'not slow and not integration': 418 passed
• targeted Ruff check passed with the pre-existing unrelated SIM117 finding excluded
• git diff --check passed
• independent frozen-diff review: approved with no blocking findings

This validates ordering and bounded fallback in CPU tests. It does not yet claim live M5 physical-memory recovery, hot-cache retention, or concurrent multi-engine performance; those remain follow-up workload measurements.

Closes #2581