[None][feat] Support V2 Mamba disaggregated serving

[VALLIS-NERIA]

@coderabbitai summary

Stack

• Base branch: agent/v2-mamba-snapshot-reuse-core
• Prerequisite: VALLIS-NERIA/TensorRT-LLM#8
• This PR contains exactly one commit relative to its base.

Description

This PR adds disaggregated context-to-generation state transfer for the V2 Mamba hybrid cache manager.

The changes:

• Represent a Mamba layer group in transfer metadata with its state-pool address, byte stride, and layer count, and preserve those fields through serialization.
• Extract V2 convolution and SSM pages from the actual KVCMv2 physical pools, including coalesced equal-size state pools, and transfer them through the Python/NIXL transceiver while preserving legacy layer-major registration.
• Reconstruct peer-side Mamba state pages for both matching and mismatched tensor-parallel layouts.
• Select the V2 manager only after resolving the effective backend and runtime: V2 requires NIXL + Python; auto/default, explicit C++, and UCX routes remain on the C++ manager unless model runtime resolution selects Python/NIXL.
• Add model-level preferred-runtime selection for the supported hybrid architectures.
• Cover runtime/backend routing, metadata round trips, page extraction, same-TP transfer, TP-mismatch transfer, and inflight-cancellation gating.

This PR does not depend on the save-last snapshot-reuse follow-up.

Test Coverage

• CPU routing, transceiver, serialization, and pointer tests (64 passed)
• CUDA V2 page-table tests (2 passed)
• V2-to-V2 Python/NIXL transfer with matching and mismatched TP (2 passed)
• Mixed/V2 native transfer, physical-pool registration, and routing regressions (18 passed)
• pre-commit run --from-ref 0ff3a34e47 --to-ref HEAD

The history squash was tree-preserving; no code changed during the squash.

PR Checklist

• Please check this after reviewing the above items as appropriate for this PR.

[Shixiaowei02]

layer_slot0_addresses looks like it could be derived rather than stored. In the single contiguous pool it's equivalent to base_address + lid*num_slots*stride, so it may be redundant. And physical_slot_stride_bytes captures a genuinely necessary concept, but perhaps a single field would suffice since the conv/ssm pair is always equal (and derivable from the two slot_bytes summed). block_stride_bytes might also read a bit more clearly.

[VALLIS-NERIA]

In KVCacheManagerV2 the states are arranged in slot-first order, so we can't reuse the calculation of V1.

[Shixiaowei02]

Would it be worth collapsing these four fields into a single optional slot_stride_bytes on PhysicalPool (defaulting to slot_bytes)? The per-layer slot0_addresses look derivable from base_address + lid*num_slots*stride, and the conv/ssm stride pair is always equal, so one stride field would let V1 and V2 share the same pointer formula (V1 just falls back to slot_bytes, unchanged). It also reads a bit more naturally, since "a slot whose stride exceeds its payload" is really a property of the pool.

[VALLIS-NERIA]

conv/ssm stride pair is always equal

This is not true in V2.