Purpose

When Triton-CPU is installed and active (the default in x86 Docker images since 0.22.0), the @triton.jit kernels in rejection_sampler.py, block_table.py, and llm_base_proposer.py can run natively on CPU — but they fail to compile due to int32/int64 type mismatches that Triton-CPU's stricter compiler catches.

This PR:

1. Fixes the type mismatches in 5 Triton kernels by replacing 0 (int32) with tl.zeros([], dtype=tl.int64) in conditional branches where the else-path produces int64 from tl.load(). This is backward-compatible with CUDA Triton.
2. Skips the C++ monkey-patches when HAS_TRITON is True (i.e., Triton-CPU backend is detected), letting native Triton kernels execute directly. The C++ fallback implementations remain for environments without Triton-CPU.

Kernels fixed

• expand_kernel
• rejection_greedy_sample_kernel
• rejection_random_sample_kernel
• sample_recovered_tokens_kernel
• eagle_prepare_inputs_padded_kernel

Root cause

Triton-CPU requires type consistency across if/else branches:

# BEFORE (fails on Triton-CPU):
start_idx = 0 if req_idx == 0 else tl.load(ptr + req_idx - 1)
#           ^^^ int32                ^^^^^^^^^^^^^^^^^^^^^^^^^ int64

# AFTER (works on both CUDA and CPU Triton):
start_idx = tl.zeros([], dtype=tl.int64) if req_idx == 0 else tl.load(ptr + req_idx - 1)

Ref: #42638 (comment)

Test plan

• All 5 fixed kernels compile and produce correct results on Triton-CPU (tested in vllm/vllm-openai-cpu:v0.22.0 Docker image)
• _compute_slot_mapping_kernel already works on Triton-CPU (no fix needed)
• Verify SD inference end-to-end on x86 CPU Docker image (Triton-CPU present)
• Verify no regression on GPU CI (type fix is backward-compatible)