Stabilize CP HiCache residency under L1/L2 pressure

CP shared KV now keeps explicit L1 and host free-room targets so pressure is handled by planned eviction instead of repeated capacity-edge retries. The host allocator gains contiguous-preferred page reservation, L1 owner-lane allocation prefers contiguous physical pages, and CP HiCache metadata preserves pending backup safety for page-granular radix updates. Mooncake transfer stats and allocator microbenchmarks are included to make the remaining transfer bottlenecks measurable rather than inferred.

Constraint: CP shared KV uses decode CP size 1 with all prefill CP ranks participating in transfer, so L1/L2 cache residency must remain page-granular and avoid extra collectives.\nConstraint: Production HiCache can be hundreds of GB, so allocator metadata overhead must be visible before enabling aggressive contiguous allocation broadly.\nRejected: Evict only the exact deficit | this keeps the cache at the cliff and causes repeated evict/allocate pressure.\nRejected: Rely on allocator scans alone for contiguity | remote microbenchmarks show fragmented 220GB-equivalent host metadata can make contiguous-preferred scans multi-ms.\nConfidence: medium\nScope-risk: moderate\nDirective: Do not increase L1/L2 free-room defaults or add new CP collectives without ETE evidence and transfer/allocator measurements.\nTested: python -m py_compile on touched runtime/test/benchmark files.\nTested: PYTHONPATH=. python -m pytest -q test/registered/unit/benchmark/test_cp_hicache_allocator_bench.py => 4 passed, 1 warning.\nTested: Remote g0034 log /mnt/beegfs/cjy/log/sglang_cp_hicache_20260601_233723.log shows active prefill process with L1/L2 free-room args, 702 HTTP 200 chat completions, 6272 prefill batches, and no fatal scheduler traceback in latest scan.\nTested: User-reported L1/L2 cache ETE validation passed on remote run.\nNot-tested: Full local pytest suite; local environment is missing several runtime dependencies.\nNot-tested: CUDA allocator microbenchmark during active production prefill process.\nNot-tested: Mooncake straggler fix; stats show transfer tail latency remains a separate bottleneck.

docs/advanced_features/nsa_prefill_cp_hicache_reactive_host_free_room_plan.md

@@ -203,3 +203,30 @@ Runtime validation:
    eviction may still fail; failures must stay explicit and warning-level.
 4. The first version does not improve physical page contiguity; it only reduces
    eviction frequency.
+
+## 2026-06-02 correction: trigger and target are separate
+
+The first draft only added target room when `required > available`.  The current
+accepted contract separates **when** eviction starts from **how far** eviction
+continues:
+
+```text
+if available >= required + trigger_room:
+    deficit = 0
+else:
+    deficit = max(0, required + target_room - available)
+```
+
+This keeps remaining cache usable when the current reservation fits, while still
+making a triggered eviction release enough extra room to reduce repeated eviction
+and give subsequent allocators a better chance of finding contiguous page runs.
+
+Implications:
+
+- `trigger_room=0` preserves the conservative behavior: evict only when the
+  current reservation would not fit.
+- `target_room>0` makes a triggered eviction release extra pages.
+- L1/device and L2/host should use the same trigger/target model, but with
+  separate ratios because L1 hit value and host capacity pressure are different.
+- Free-room alone is not sufficient for contiguous allocation. `HostKVCache` and
+  CP owner-lane device allocation also need contiguous-preferred selection.