fix(io): use anonymous mmap + cudaHostRegister for io_uring bounce buffers

[mbrobbel]

Problem

Loading the extension on an older kernel (reported on a DGX A100, kernel 5.4.0-182-generic) aborts at startup:

terminate called after throwing an instance of 'std::runtime_error'
  what(): uring_device_reactor: io_uring_register_buffers: Operation not supported

"Operation not supported" is EOPNOTSUPP. The uring_reactor registers its pinned bounce slots as io_uring fixed buffers via io_uring_register_buffers(). On the non-NUMA path (the scan_manager default, numa_node = -1) those slots were allocated with cudaHostAlloc(), whose VMA is backed by the NVIDIA device file.

IORING_REGISTER_BUFFERS requires anonymous, non-file-backed memory and rejects file-backed VMAs with EOPNOTSUPP. Kernels that still carry the explicit vma->vm_file check (pre-6.x) therefore reject CUDA-pinned memory; newer kernels delegate the check to GUP and accept it — which is why this only reproduces on the older kernel. (Not a RLIMIT_MEMLOCK/ENOMEM or io_uring_disabled/EPERM issue.)

Fix

Allocate the non-NUMA bounce slots with mmap(MAP_ANONYMOUS) + cudaHostRegister instead of cudaHostAlloc:

• The VMA stays anonymous, so io_uring_register_buffers() succeeds on all kernel versions.
• cudaHostRegister pins it in place without changing the backing, so GPU-pinned H2D copies are unaffected.
• This is exactly the existing NUMA path minus the node binding (numa_alloc_onnode is itself anonymous mmap + mbind), so the approach is already exercised in the multi-GPU path.
• MAP_ANONYMOUS is page-aligned, satisfying the O_DIRECT device-read fd's alignment requirement.

Also makes slot allocation exception-safe: the per-slot free is factored into release_bounce_slot(), and the constructor now releases any already-populated slots if a later slot fails to allocate or pin (the destructor does not run for a partially-constructed object, so the previous code could leak pinned host memory on a mid-loop failure).

🤖 Generated with Claude Code

[GregoryKimball]

@aminaramoon what did the fix end up being?

[aminaramoon]

@GregoryKimball it will be ready later in the week, if you need it now, we can reopen this PR and merge it today. but the entire IO stack is being revamped and merged early next week