NanoVDB: run the builders on a synchronous memory resource (CUDA)

[harrism]

Follow-up to #2231/#2251, part of #2232. This closes the scratch half of step 2's acceptance criterion: "NanoVDB builds and runs on a pool-less vGPU via an injected synchronous cudaMalloc-backed resource."

Stacked on #2270 — review the last commit.

What

The builders require a stream-ordered resource, which a device without memory-pool support (cudaDevAttrMemoryPoolsSupported == 0, e.g. AWS g6f, cf. #2255) cannot provide through cudaMallocAsync — the wrappers fail loudly there by design (#2256). Two additions close the gap as pure library code:

• cuda::MallocResource — a synchronous cudaMalloc/cudaFree resource that works on any device. Models is_resource only.
• cuda::AsyncFromSync<R> — presents a synchronous resource as a stream-ordered one; the mirror of SyncFromAsync, and the analog of cuda::mr's synchronous_resource_adapter. allocate_async forwards — synchronously allocated memory is already valid on every stream, a stronger guarantee than stream-ordering requires. deallocate_async synchronizes the stream first, which makes the synchronous contract's quiescence requirement hold.

So the pool-less path is PointsToGrid<BuildT, AsyncFromSync<MallocResource>> (or an AsyncFromSync<ResourceRef<YourArena>> for a stateful arena), with no build flags.

Why a wrapper rather than dispatch inside the builders

The roadmap's rule is that a synchronous arena is never a silent allocate_async facade — a facade misrepresents its semantics and hands multi-stream callers unexpected serialization. AsyncFromSync is the explicit, honest version of the same lift: every deallocation synchronizes its stream, that cost is documented at the type, and the caller chooses it. This is also exactly the design CCCL settled on (synchronous_resource_adapter synchronizes before deallocate_sync when wrapping a synchronous resource). The alternative — if constexpr dispatch at every builder release site — spreads the same synchronization across ~30 sites instead of one audited method.

What this does not close

The grid handle's buffer still goes through GridHandle<BufferT>'s buffer type (default DeviceBuffer → cudaMallocAsync), so a fully flag-free pool-less deployment still needs NANOVDB_USE_SYNC_CUDA_MALLOC for that one allocation until step 3 delivers GridHandle<cuda::Buffer<std::byte,R>>. Scratch — the overwhelming majority of allocations — is closed here.

Testing

New TestMemoryResource.PointsToGrid_RunsOnSynchronousResource: drives PointsToGrid end-to-end with AsyncFromSync<ResourceRef<SyncCountingResource>> — a stateful, synchronous-only resource. Asserts the grid builds, that scratch really routed through the synchronous resource (allocs > 0), and that every allocation was freed through the caller's instance (allocs == deallocs). On pooled hardware this path bypasses pools entirely, which is precisely what a pool-less device requires, so the dispatch is exercised without vGPU hardware; final validation on a real g6f would be a good CI follow-up once #2264 lands. Plus static_asserts pinning the tiers (MallocResource is sync-only; the wrapper models async).

Suites: memory-resource 10/10, TestBuffer 27/27, full CUDA 52/53 (pre-existing UnifiedBuffer_IO data-file failure). Per #2264, CI builds but does not run these — numbers are from a local RTX 6000 Ada, CUDA 12.6.

[harrism]

Copilot cycles (fork mirror: harrism#4). Net changes (aac7f00): the sync-resource test's comment now says scratch allocations and names the grid handle's output buffer as the exception, and AsyncFromSync::deallocate_async treats null as a no-op rather than synchronizing for it. Second cycle returned no findings.