Fix legacy RC QP indexing for NVSHMEM 3.5.19+

[heyselbi]

Summary

• Port deepseek-ai/DeepEP#696 / the fix vendored by vllm-project/vllm#58159 into midstream DeepEP
• Fix legacy IBGDA ibgda_get_rc indexing for NVSHMEM 3.5.19+ (QP-major, PE-interleaved RC QP layout); keep PE-major indexing for older NVSHMEM
• Add compile-time version gates plus a runtime host/device layout compatibility check before NVSHMEM init to avoid CUDA illegal memory access on first RDMA dispatch
• Bump midstream version to 2.0.1+rhaiv.5 (setup.py + pyproject.toml) so the next tag matches the wheel version (ADR-170)

Context

DeepEP v1 legacy low-latency / high-throughput all2all IBGDA kernels used the pre-3.5.19 RC QP layout. Building against NVSHMEM 3.5.19+ (including PyTorch 2.15 / NVSHMEM 3.7) can fault on first RDMA dispatch. The original fix in deepseek-ai#564 was lost in the DeepEPv2 upgrade; deepseek-ai#696 restores it.

Once this lands, cut tag v2.0.1+rhaiv.5. vLLM can then drop its temporary build-time patch once it pins that revision.

Test plan

• Confirm patch matches upstream DeepEP#696 / vLLM vendored deepep_nvshmem_rc_qp.patch
• Build against NVSHMEM ≥3.5.19 and exercise multi-node dispatch/combine (no IMA / hang)
• Confirm wheel version resolves to 2.0.1+rhaiv.5
• Optionally verify older NVSHMEM (<3.5.19) still uses PE-major indexing path

[heyselbi]

Note for anyone rebuilding this against a stripped production RHAIIS image (e.g. registry.redhat.io/rhaii/vllm-cuda-rhel9):

Building DeepEP via uv pip install --no-build-isolation against the torch bundled in those images can hit half/bf16 operator errors in nvshmem.cu / NVSHMEM's reduce.cuh. That comes from PyTorch's cpp_extension.py injecting -D__CUDA_NO_HALF_OPERATORS__ (and related flags), which conflicts with NVSHMEM's unconditional half/bf16 reduce macros.

AIPCC's fondue/builder path does not need this — leave nvcc_flags as-is for the real midstream build. For a local rebuild only, appending these to setup.py's nvcc_flags unblocks it:

'-U__CUDA_NO_HALF_OPERATORS__',
'-U__CUDA_NO_HALF_CONVERSIONS__',
'-U__CUDA_NO_BFLOAT16_CONVERSIONS__',
'-U__CUDA_NO_BFLOAT16_OPERATORS__',
'-U__CUDA_NO_HALF2_OPERATORS__',

Those production images are also runtime-only (no -devel headers for NVSHMEM/NCCL/cuBLAS/cuSPARSE/cuSOLVER/NVRTC, and no mlx5dv.h). Matching nvidia-*-cu13 wheels from PyPI plus exact-version devel RPMs from NVIDIA's public CUDA repo (header extract only) are enough to get a local rebuild working; again, not needed for AIPCC.