Builds on #1755 (which exposed DFlashEngine.scheduler for fallback mode) and the recent move of the prefill guard to HTTP 400. Those land the guard for DFlash's fallback path; this PR adds the missing primary-mode guard so DFlash is protected in both modes, reusing the same machinery rather than reshaping it.

Summary

• DFlash's primary (speculative) path bypasses the Scheduler, so it inherited BaseEngine's no-op preflight_chat/preflight_completion and ran prefills with no memory guard — a long prompt could OOM the process instead of returning a clean HTTP 400.
• Give DFlash a _DFlashPrefillGuard (built in start()) plus preflight_* overrides that estimate the prefill peak and raise PrefillMemoryExceededError; in fallback mode they delegate to the fallback engine, whose scheduler already runs the full guard.
• The ProcessMemoryEnforcer reaches the new guard through a small _prefill_guard arm in _resolve_scheduler.

Why

After #1755, DFlashEngine.scheduler resolves the fallback engine's scheduler, so the enforcer can propagate watermarks once DFlash enters fallback mode. But in normal speculative mode DFlash has no scheduler at all — the enforcer had nowhere to push the ceiling, and the front-door preflight was still BaseEngine's no-op. An oversized prompt served on the primary path therefore skipped the guard entirely and could drive the process past the memory ceiling (observed end-to-end serving Qwen3-Coder-Next + DFlash with 56k-token prompts). This closes that primary-mode gap with the same pieces #1755 and the 400 handler already established.

Changes

• omlx/memory_monitor.py: two additive, engine-agnostic helpers — set_model_info_from_model() (populate a MemoryMonitor's KV/SDPA dims from an mlx-lm model; CacheList-aware layer counting, matching Scheduler._set_model_info_for_monitor) and raise_if_prefill_exceeds() (the shared peak-estimate-and-raise). Scheduler is intentionally left untouched — it keeps its own (now TurboQuant-coupled) copy, so this PR doesn't reshape the scheduler hot path or its preflight math.
• omlx/engine/dflash.py: _DFlashPrefillGuard holds a MemoryMonitor + the enforcer's watermark attrs; preflight_chat/preflight_completion estimate the peak and raise, or delegate to the fallback engine in fallback mode. Coexists with the scheduler property added in engine/dflash: expose scheduler property for ProcessMemoryEnforcer #1755.
• omlx/process_memory_enforcer.py: _resolve_scheduler resolves a primary-mode DFlash to its _prefill_guard (None for every other engine, so standard resolution is unchanged). Fallback-mode resolution and the "could not resolve scheduler" warning suppression are already handled by engine/dflash: expose scheduler property for ProcessMemoryEnforcer #1755 and untouched here.
• The guard uses the uncompressed (base-dtype) KV estimate — the conservative, never-undercount choice for an OOM guard.

Tests

New tests/test_dflash_prefill_memory_guard.py (12 cases: guard math mirroring test_scheduler_prefill_memory_guard, plus engine-level delegation including fallback-mode pass-through) and TestDFlashGuardPropagation in tests/test_process_memory_enforcer.py (enforcer reaches the primary guard; standard engines unchanged; no spurious warning).

.venv/bin/python -m pytest tests/test_dflash_prefill_memory_guard.py \
  tests/test_process_memory_enforcer.py tests/test_dflash_engine.py \
  tests/test_engine_preflight.py -q
# 198 passed

Also verified the new tests fail when the fix is reverted: neutralizing raise_if_prefill_exceeds makes test_preflight_raises_when_oversized fail with "DID NOT RAISE".