cuda.core: a fast-path VMM grow leaves its extension unfreeable

Summary

_grow_allocation_fast_path maps a new chunk into a second, adjacent VA reservation and updates buf._size in place. The Buffer's deleter captured the original size when the buffer was created, so close() calls deallocate(ptr, original_size) and frees only the first reservation. The extension's reservation, mapping, and physical memory leak with no warning.

No deallocate(ptr, size) call can fix this: cuMemAddressFree frees a reservation only when ptr and size match exactly one reservation, so a range that spans two reservations cannot be freed in one call. The buffer needs to own each reservation and mapping it consists of.

Status

Today the fast path is unreachable (#2388 defect 2). #2237 and #2407 make it live and would expose this leak, so they should wait for this fix. The existing fast-path test mocks the driver and cannot catch it.

Refs: #2388, #2237, #2407, #2882.

Start at _grow_allocation_fast_path and trace how Buffer, close(), and deallocate(ptr, size) manage reservations, mappings, and physical memory. Review the existing fast-path test, then add coverage that detects the extension reservation remaining allocated after close; done means every reservation and mapping owned by the buffer is released.