feat(scheduler): split store_cache_main_prep into sub-phase timers

[ivaniguarans]

Summary

store_cache_main_prep wraps three distinct operations as a single timing measurement — boundary override lookup, KV array collection, and async_eval dispatch. When diagnosing store-cache overhead across model architectures (standard transformer vs GatedDeltaNet/ArraysCache vs MoE), the aggregate doesn't reveal which sub-step dominates. On ArraysCache models, for example, collect and dispatch are both near-zero (empty pre_eval_arrays), but the single timer can't distinguish that from a model where boundary merge dominates.

Changes

Split into three sub-phase timers following the boundary_capture_sync / boundary_capture_extract / boundary_snapshot_save pattern already in use:

• store_cache_main_boundary — boundary override lookup + optional merge with full cache
• store_cache_main_collect — _collect_arrays_from_extracted_cache traversal
• store_cache_main_dispatch — mx.async_eval enqueue

The mx.stream(generation_stream) context remains the outer wrapper. No behavioral change — only diagnostic granularity.

Test plan

• Full test suite: 4321 passed, 0 regressions (9 pre-existing failures unrelated)
• Log output changes from store_cache_main_prep=X.Xms/N to three separate entries
• Complements the cache observability work in feat(cache): add per-model cache hit-rate observability #1183

[jundot]

Thanks for this. The split matches the existing boundary_capture_* timers and is directly useful for the paged SSD store-cache perf work. Confirmed no other references to store_cache_main_prep and the phase-stats log iterates generically, so the new names surface on their own. Merging for the next release.