fix(cuda.core): resize VMM deallocation metadata

[aryanputta]

Summary

Fixes #2887.

The VMM fast path grows a Buffer in place, but the C++ MemoryResource deleter previously retained the original allocation size. This change keeps the deleter metadata synchronized with the grown buffer so closing it releases the complete VMM reservation.

Changes

• store the MemoryResource deallocation size in the shared C++ device-pointer box;
• add an internal update path for in-place VMM growth;
• update the size after a successful fast-path grow;
• extend the fast-path regression coverage.

Validation

• pre-commit passed: Ruff, Ruff format, SPDX, stub generation, mypy, and repository checks;
• git diff --check passed;
• full CUDA/GPU pytest validation was unavailable on the macOS development host.

The branch is DCO signed and contains only the issue-focused changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Andy-Jost]

Thanks for the PR. VMM work is consolidated under #2906.

This cannot fix #2887, for a driver reason: cuMemAddressFree frees a reservation only when ptr and size match exactly one reservation (driver API docs). A fast-path-grown range spans two reservations, so deallocate(ptr, grown_size) unmaps both chunks and then fails at address-free; both reservations leak, and every close of a grown buffer emits a CUDAWarning. Two smaller points: Buffer._set_deallocation_size is a cdef method, so the pure-Python resource cannot call it (the FakeBuffer test hides this), and the new field widens DevicePtrBox for every device pointer.

The fix needs the buffer to own each reservation and mapping, which is the redesign in #2906. Closing. Reviews of the redesign PR are welcome.