Test: `TestDeallocation.test_max_pending_count` is flaky

[leofang]

https://github.com/NVIDIA/numba-cuda/actions/runs/24417845685/job/71332295933#step:15:4517

=================================== FAILURES ===================================
___________________ TestDeallocation.test_max_pending_count ____________________
[gw11] linux -- Python 3.13.13 /opt/hostedtoolcache/Python/3.13.13/x64/bin/python

self = <numba.cuda.tests.cudadrv.test_deallocations.TestDeallocation testMethod=test_max_pending_count>

    @skip_if_external_memmgr("Deallocation specific to Numba memory management")
    def test_max_pending_count(self):
        # get deallocation manager and flush it
        deallocs = cuda.current_context().memory_manager.deallocations
        deallocs.clear()
        self.assertEqual(len(deallocs), 0)
        # deallocate to maximum count
        for i in range(config.CUDA_DEALLOCS_COUNT):
            cuda.to_device(np.arange(1))
>           self.assertEqual(len(deallocs), i + 1)
E           AssertionError: 10 != 9

/opt/hostedtoolcache/Python/3.13.13/x64/lib/python3.13/site-packages/numba_cuda/numba/cuda/tests/cudadrv/test_deallocations.py:30: AssertionError

[xyaz1313]

根因分析：

测试中每次迭代 cuda.to_device(np.arange(1)) 创建的 DeviceNDArray 没有被变量引用。底层的 OwnedPointer 使用 weakref.finalize 注册析构器，当 Python GC 非确定性地回收这些临时对象时，finalizer 会提前触发，向 pending deallocation 队列添加额外条目，导致 len(deallocs) 超过预期值。

修复方案：先创建所有 device array 并保持引用，然后逐个 del + gc.collect() 确保析构确定性执行。PR: #857

[gmarkall]

As per #857 (comment), I'm a little worried that it's our deallocation behaviour that's flaky (and inefficient).

[gmarkall]

Although, looking at the specific counts in that failure:

>           self.assertEqual(len(deallocs), i + 1)
E           AssertionError: 10 != 9

If there are more deallocations in the list than expected, then it seems more plausible that the state is getting polluted by some previous test, where a device array is caught in a lost reference cycle. If the GC does run in the middle of the loop in the test, then the device array from the previous test will suddenly appear in the deallocation list, bumping its length up to one greater than expected.

I think if this were the case, then running gc.collect() just before deallocs.clear() would guard against this specific scenario, by ensuring there were no lost device arrays hanging around that could interfere with the test during the loop execution.