[Core][Refactor]: thread scheduler_block_size into KVCacheManager and KVCacheCoordinator

[ivanium]

Purpose

This is a small, behavior-preserving refactor that threads an explicit scheduler_block_size through KVCacheManager → KVCacheCoordinator → SingleTypeKVCacheManager, instead of having HybridKVCacheCoordinator recompute the LCM of group block sizes internally.

Today the scheduler already resolves the scheduling-alignment granularity via resolve_kv_cache_block_sizes (returned as scheduler_block_size, the LCM of all group block sizes for the multi-group non-context-parallel case) and stores it as Scheduler.block_size. Separately, HybridKVCacheCoordinator independently recomputed the same quantity as self.lcm_block_size = lcm(*block_sizes). This PR removes that duplicate computation and instead passes the already-resolved value down, making the alignment invariant a single explicit input rather than a value derived in two places.

This is a preliminary step in prep for refactoring/merging #43447 (selective prefix-cache retention for sliding-window KV cache), which needs the scheduling block size available at the manager/coordinator level. Landing the plumbing on its own keeps that follow-up focused on the retention logic.

Behavioral equivalence

• HybridKVCacheCoordinator.cache_blocks and find_longest_cache_hit now align on self.scheduler_block_size instead of self.lcm_block_size. For the only configuration that reaches HybridKVCacheCoordinator (multiple KV cache groups, context parallelism disabled), resolve_kv_cache_block_sizes returns exactly math.lcm(*group_block_sizes) — identical to the old internal computation over the same set of groups. Hybrid groups + context parallelism is rejected upstream in resolve_kv_cache_block_sizes, so there is no configuration where the two values could diverge.
• self.scheduler_block_size is also stored on SingleTypeKVCacheManager. It is not consumed yet in this PR; it is the plumbing that [Prefix Caching] DeepSeekv4 - Support selective prefix-cache retention for sliding-window KV cache #43447 builds on.

All get_kv_cache_coordinator / KVCacheManager constructor sites are updated (scheduler and simple_kv_offload). The Mooncake store path uses its own coordinator and already carries its own scheduler_block_size; it is untouched here.

Why this is not duplicating an existing PR

A search of open PRs (scheduler_block_size, block-size threading into KVCacheManager) returns no overlap. #36317 ("Adjust alignment block size according attn supported kernel sizes") changes how the alignment block size is chosen per attention kernel — a different concern from threading the already-resolved value through the manager/coordinator. This PR adds no new behavior and changes no defaults.

Test Plan

.venv/bin/python -m pytest \
  tests/v1/core/test_prefix_caching.py \
  tests/v1/core/test_single_type_kv_cache_manager.py \
  tests/v1/core/test_kv_cache_utils.py -v

Tests are updated to pass scheduler_block_size. test_prefix_caching.py adds a small make_kv_cache_manager helper that derives scheduler_block_size from the config (LCM of group block sizes), mirroring resolve_kv_cache_block_sizes for the non-context-parallel path so call sites don't repeat it.

Test Result

126 passed in 35.08s

pre-commit run (ruff, mypy) passes on all changed files.

---

AI assistance (Claude Code) was used while preparing this change. The submitter has reviewed every changed line and run the tests above.

[njhill]

Thanks @ivanium

[njhill]

Could/should we add an assert here for this?