[HiCache] Batch buffer-only KV backups within each flush

[metamergebot]

Motivation

In buffer-only HiCache mode, BufferModePipeline.flush_pending_writes launched one D2H transfer per admitted backup intent: each cc.write(...) allocated host staging, queued a CacheOperation, and immediately called start_writing(), so seven pending backups cost seven merge_ops + submit_device_to_host round trips on the scheduler's critical path. HybridCacheController.write already accepts flush=False for exactly this case; the buffer pipeline did not use it.

Modifications

• flush_pending_writes now stages every admitted intent with flush=False (host staging + device lock, no L1 allocation or free), removes the successes from pending_write_queue, and submits them together with a single cc.start_writing() before returning. An intent that runs out of staging still defers head-of-line, and the earlier successes are still submitted rather than left prepared across scheduler admission, so each staged source stays locked until its D2H ack.
• _launch_backup_intent is renamed _stage_backup_intent; it no longer submits.
• Tests: the sidecar test asserts the pipeline stages with flush=False. test_buffer_only_write_path_roundtrip in the unified radix cache suite now drives flush_pending_writes with the L1 allocator's alloc*/free* patched to raise, then asserts one merged HiCacheAck carries every pending node id, that GPU completion alone releases no device lock, and that writing_check releases them all while each storage write keeps its own staging until its separate ack.

Accuracy Tests

No numerics change: the same bytes travel D2H, in one submission instead of several.

Speed Tests and Profiling

Isolated BF16 measurement of one flush's CPU preparation/enqueue time, FULL+SWA pools, 128-token pages, median of 30 paired runs on one GPU:

Pending backups	Pages per backup	Before (ms)	After (ms)
1	1	0.644	0.638
7	1	3.398	1.843
1	4	0.912	0.901
7	4	5.078	2.478

Checklist

• pre-commit hooks (isort, ruff, ruff-format, codespell) run on the three files: clean.
• test/registered/unit/mem_cache/test_buffer_mode_sidecar.py: 1 passed locally on this branch.
• test/registered/unit/mem_cache/test_unified_radix_cache_unittest.py -k test_buffer_only_write_path_roundtrip: 13 passed, 6 skipped locally on this branch (1 GPU). With main's pipeline.py and this branch's test file the same selection fails, so the extended test guards the change.
• test/registered/unit/mem_cache/test_rust_unified_radix_cache_unittest.py -k test_buffer_only_write_path_roundtrip (same suite on the Rust TreeCore, via unittest): 19 ran, OK, 6 skipped.
• Documentation: none affected.

---

CI States

Latest PR Test (Base): 🚫 Run #35941513898
Latest PR Test (Extra): ❌ Run #35941513580
Latest PR Test (AMD ROCm 10): ❌ Run #35941513871

[metamergebot]

This port clears our bar on e3ea1830eea5ab92a450930837915c3c3a51cd13: every base-a and base-b job is green.
base-c and the accelerator suites are reported but not gated, because they run
on scarce hardware and upstream merges through them routinely.

gate 18✓✗1 lint✓ build 3✓✗1✂3 A✓ B✓ C✗6⏳4 other✓ · accel ✗amd,b200,npu,xpu

@pranjalssh @merrymercy @Jialin — could one of you take a look and merge it if you are happy? Nothing else is waiting on our side.