[hardware] feat: add ROCm/HIP platform backend (PlatformROCm)

[xiaohong42]

What does this PR do?

Add a dedicated PlatformROCm backend so ROCm is a first-class platform instead of falling back to PlatformCUDA. ROCm is largely CUDA-compatible (PyTorch reuses torch.cuda.* via hipify), so PlatformROCm subclasses PlatformCUDA and only overrides what differs, extending the parent via super().

Checklist Before Starting

• Search for similar PRs: https://github.com/volcengine/verl/pulls?q=is%3Apr+PlatformROCm (none)
• PR title format [hardware] feat: add ROCm/HIP platform backend (PlatformROCm) — not a breaking change.

Test

Validated on AMD ROCm (ROCm 7.0, 8x gfx942 / MI3xx):

• get_platform() resolves to PlatformROCm (not PlatformCUDA); PlatformCUDA.is_platform_available() returns False on ROCm.
• vendor_name='amd', device_name='cuda', is_platform_available(use_smi_check=True)=True.
• rollout_env_vars() = {'NCCL_CUMEM_ENABLE': '0', 'SGLANG_USE_AITER': '1'}; with SGLANG_USE_AITER=0 exported it becomes '0' (override honored).
• ray_noset_envvars() includes CUDA + HIP + ROCR NOSET vars.

CI cannot cover this (requires ROCm hardware); validated manually.

API and Usage Example

No API change. ROCm is auto-detected; AITER can be disabled by the user:

export SGLANG_USE_AITER=0   # fall back to vLLM RMSNorm/RoPE kernels

Design & Code Changes

• verl/plugin/platform/platform_rocm.py (new) — PlatformROCm(PlatformCUDA): vendor_name="amd" (device_name stays "cuda"); inherits is_available from PlatformCUDA; overrides is_platform_available (gated on torch.version.hip, mirroring the parent's smi-check structure but using rocm-smi); rollout_env_vars adds SGLANG_USE_AITER (user-overridable); ray_noset_envvars adds HIP/ROCR NOSET vars.
• platform_cuda.py — is_platform_available returns False when torch.version.hip is not None, so auto-detection picks ROCm on AMD.
• platform_manager.py — register PlatformROCm.
• tests/special_sanity/check_device_api_usage.py — whitelist platform_rocm.py (reuses torch.cuda via hipify).

Notes on specific decisions:

1. is_platform_available mirrors PlatformCUDA — kept structurally aligned with the parent (HIP build check, then optional smi probe, then torch.cuda.is_available() fallback), only swapping nvidia-smi for rocm-smi (with a /opt/rocm/bin lookup). The leading torch.version.hip gate is what distinguishes ROCm from NVIDIA during auto-detection.
2. SGLANG_USE_AITER in rollout_env_vars — defaults to "1" but reads os.environ.get(...) so users can override.
3. visible_devices_envvar stays CUDA_VISIBLE_DEVICES — verl drives visibility via CUDA_VISIBLE_DEVICES and keeps HIP_VISIBLE_DEVICES unset; the HIP side is handled by ray_noset_envvars (preventing Ray from clearing it). Switching the primary variable to HIP would flip many read/write sites and conflict with Ray's GPU assignment.

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks: all hooks pass.
• Add / Update the documentation — N/A (internal platform abstraction, no user-facing doc change).
• Add unit or end-to-end test(s)... If not feasible, explain why: requires ROCm hardware; validated manually (see Test).
• (For upstream) send a message in the ci-request channel when ready for CI.
• Not related to the recipe submodule.