[ROCm] Restore Wave64 warp size for all gfx9 targets

[0xDELUXA]

PR #2012 narrowed the HIP warp size condition in csrc/common.cuh from defined(__GFX9__) to IS_CDNA, which matches only gfx908, gfx90a, gfx942 and gfx950. The pre-CDNA gfx9 parts (gfx900 through gfx90c) and the gfx940/gfx941 CDNA3 revisions are Wave64 as well, and now resolve BNB_WARP_SIZE to 32.

That value gates the block primitive choice in kQuantizeBlockwise. With a 32-thread block and a warp size reported as 32, the guard in csrc/kernels.cu selects BLOCK_LOAD_WARP_TRANSPOSE, and rocPRIM rejects it through BlockSize % wavefront::min_size() == 0 because the hardware wavefront is 64. Building with BNB_ROCM_ARCH=gfx900 or gfx906 therefore fails on ROCm 7.16 with that static assert in every blocksize-64 kQuantizeBlockwise instantiation. Restoring the __GFX9__ test fixes both the build and the reported warp size. IS_CDNA stays as it is, so the 4-bit GEMM math path dispatch is unchanged, and gemm_4bit_simt.cu is unaffected either way since it uses fixed 32-lane subgroups rather than BNB_WARP_SIZE.

Verified on ROCm 7.16 by compiling csrc/kernels.cu, csrc/ops.cu, csrc/gemm_4bit.cu and csrc/gemm_4bit_simt.cu for gfx900, gfx906, gfx90a, gfx1030, gfx1100, gfx1200 and gfx1250: gfx900 and gfx906 fail before the change, every target compiles after it. A full Windows wheel spanning 27 targets including gfx900 and gfx906 builds and packages cleanly: https://github.com/0xDELUXA/bitsandbytes_win_rocm/releases/tag/0.50.2.dev0-py3.12-rocm7.16-win_amd64_all.

cc @sstamenk

[sstamenk]

LGTM, cc @matthewdouglas

[github-actions]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[matthewdouglas]

Thanks!

[0xDELUXA]

Glad to contribute!