fix(rocm): refuse wave32-only kernel ports on wave64 devices

[inureyes]

Summary

The shuffle-based HIP ports have only run on 32-lane wavefronts, and their #error guards on __AMDGCN_WAVEFRONT_SIZE are inert because AMD clang 23 defines neither macro spelling (rechecked here with hipcc -E -dM for gfx1151, gfx942 and gfx90a). This PR holds those ports to 32-lane devices at port selection, so a wave64 (CDNA) device takes the graph fallbacks instead of running unvalidated kernels. Nothing changes on gfx1151.

What changed

• port_for (kernel_port.cpp) returns a ROCm port only when rocm_port_allowed(ports.rocm_any_wave_size, rocm_port_warp_size()), so has_kernel_port, every *_available() predicate and select_kernel_port agree. The refusal message names the width; stderr notes a non-32 wavefront once per process.
• The width is the hardware value from a new overlay call, mlx::core::rocm::device_warp_size() (hipDeviceAttributeWarpSize, ignores MLX_ROCM_FORCE_WARP_SIZE, 0 on error), recorded as LOCAL_FIXES item 32 (new "Additions to the fork's API" section; perf(rocm): batch sorted mxfp4 gather_qmm prefill by expert #2164 took 31) and stubbed in no_rocm.cpp. It clears only an HIP error it raised itself.
• KernelPorts::rocm_any_wave_size (default false) is set on the five tables whose HIP body has no lane-level operation: RoPE append, paged merge, Gumbel, rejection, and xIELU. xIELU is not in the issue's list, but checking the current code shows its body is purely elementwise; its inert guard is dropped, as the sampler and RoPE bodies already have none. The other ten ROCm tables (bitlinear, ssm, mamba1_scan, moe_gateup, moe_down, moe_fc1_relu2, add3_layer_norm, fused_norm, paged_attention, paged_v2_partial) stay wave32-only. update(rocm): port fused_add_rms_norm and fused_rope_qk_append to HIP #2107's fused norm is wave32-only (shuffles) and its RoPE port is any-wave.
• bitlinear_kernel_available now reads its port table (it returned "any GPU backend" before), so BitNet is refused at load on wave64 rather than failing mid-request.
• verify-kernel-port-dispatch: rule 5 pins the any-wave tables with their HIP source, follows each table's .rocm getter to its holder and requires exactly that source (no header argument, one raw literal), and fails on lane intrinsics, AMDGCN lane builtins, wavefront macros or 32-lane index arithmetic in it; rule 6 keeps the test seam set_rocm_port_warp_size_for_tests out of non-test code, with an exact use count in its definition files. scripts/ci/check_kernel_port_dispatch_test.sh (run by the make target and CI job) proves each rule fails on a mutated copy (13 cases).
• mamba1_selective_scan is now -> Result<()>, since select_kernel_port can refuse there; Mamba, Jamba and its parity test expect the gated launch. BitLinear's refusal names the BitNet load-time refusal instead of a graph fallback it lacks.
• Parity tests that assert a ROCm port exists (fused MoE, relu2, SSM, fused norm, Mamba1, add3) skip on a wave64 device through test_support::kernel_ports::skip_for_wave32_only_rocm_port instead of failing.
• build.rs now tracks kernel_port.* and gpu_backend.*; edits to them did not rebuild the bridge before (found when a negative check passed on a stale library).
• Guard comments now name the host-side check as the protection; docs/installation.md gains a "Wave64 devices" row; CONTRIBUTING and the paged-test skip message mention the hold.

Verification (gfx1151)

• cargo test --features rocm -p mlxcel-core --lib kernel_port: 2 passed (rocm_port_allowed truth table, runs on every backend).
• tests/rocm_wave_size.rs: device_warp_size() == 32 on gfx1151; with MLX_ROCM_FORCE_WARP_SIZE=64 in a child (the child's device log confirms the override applied) it still reads 32; all 16 port predicates are true.
• tests/rocm_wave64_port_refusal.rs, with the reported width forced to 64 through the test seam: all 11 wave32-only predicates false, the five any-wave ones true; bitlinear_matmul, fused_add_rms_norm and fused_moe_expert_kernel (moe_gateup) refuse naming the width; layers::fused_add_rms_norm (fusion on) and residual_add3_layer_norm return the graph pair's bytes. With the hold disabled in port_for, this test fails listing all 11 tables.
• Existing port tests (debug profile): fused norm, RoPE, MoE, relu2, SSM, Mamba1, Gumbel, rejection, fixed-key, paged v2, MLA, residual add3: 357 passed; 2 cache::paged_detach tests fail on a debug_assert in the dev profile only (the gate's test-fast profile has no debug assertions; unrelated to ports). Apertus, BitNet and Cohere2 tests in the mlxcel lib: 26 passed. cpu_device_custom_kernel_gates: passed.
• make verify-versions verify-kernel-dtype-keys verify-kernel-port-dispatch verify-llama-compat verify-fmt verify-rocm-overlay: pass.
• make verify-rocm on the final head (merged with origin/main 08e2269): OK, 151 test suites, 11969 passed, 0 failed, 381 ignored; clippy, smoke, overlay and script gates pass. The targeted tests above were re-run after the review fixes (29 mlxcel-core, 30 Mamba/Jamba, the three integration files): all pass.
• Meta-Llama-3.1-8B-Instruct-4bit, release binary under scripts/rocm_gpu_guard.sh (clean attempt): greedy 64 tokens with MLXCEL_FUSED_ADD_RMSNORM=0 and =1 give identical text (33.88 and 33.90 tok/s, single run, not a performance claim); rocprofv3 --kernel-trace of a sampled run shows custom_kernel_mlxcel_fused_add_rms_norm (wave32-only, 544 launches) and custom_kernel_mlxcel_gumbel_max_sample (any-wave) still selected, and no wavefront notice on stderr.

Not verified: no wave64 device is available, so the refusal is proven only through the test seam. Metal and CUDA are not available on this host; the change touches the shared KernelPorts struct and port_for, whose Metal and CUDA cases are unchanged, and bitlinear_kernel_available, which answers the same on Metal and CUDA (both tables have ports).

Closes #2147