Fall back to cudaMalloc on CUDA devices without memory pools

[Gasoonjia]

The CUDA backend's stream-ordered allocations fail on any device that does not support
memory pools, which includes data-center GPUs in TCC mode on Windows (A10G, A100, H100 and
the like). There cudaMemPoolCreate and cudaMallocAsync return cudaErrorNotSupported, and
nothing falls back:

E cuda_allocator.cpp:99] cudaMemPoolCreate failed for device 0: operation not supported. Using the default pool.
E cuda_allocator.cpp:448] cudaMallocAsync failed: operation not supported (requested 512 bytes on device 0)
F storage.h:126] In function allocate(), assert failed (result.ok()): CudaAllocator::allocate_async failed for 512 bytes on device 0

That is from a CUDA program running on the Windows GPU CI runner (an A10G) in #23123, the
first CI job to run the delegate on Windows with a driver installed. A GeForce card in WDDM
mode supports memory pools, which is why a local run passes.

Change

• CudaAllocator asks each device once whether it supports memory pools
  (cudaDevAttrMemoryPoolsSupported). On a device that does not, allocate_async allocates
  with cudaMalloc and deallocate_async frees with cudaFree, deciding by the device the
  pointer lives on. cudaFree waits for the device's outstanding work, so work still using
  the block on the stream finishes first. A failed attribute query keeps the stream-ordered
  path, so nothing changes where the query cannot answer.
• release_cached_memory skips cudaDeviceGraphMemTrim on such a device; graph memory is
  served by memory pools, so there is none to release.
• sort.cu and rand.cu called cudaMallocAsync/cudaFreeAsync directly; they now go through
  CudaAllocator, so they take the same fallback.

Devices with memory pools, which is every Linux runner and every WDDM GPU, take exactly the
path they took before.

Tests and CI

• test_cuda_allocator: AllocateAsyncRoundtrip runs on every device and fails without the
  fallback on a device without pools. FallsBackWithoutMemoryPools checks that no pool is
  created and no error is left behind there. The pool tests move to a fixture that skips on
  a device without pools, where they cannot mean anything.
• cuda-windows.yml gains unittest-cuda-runtime-windows, the Windows counterpart of
  cuda.yml's unittest-cuda-runtime: it builds llm-release-cuda with tests and runs the same
  five runtime tests. The Windows runner's A10G has no memory pools, so this covers the
  fallback; the Linux job covers the pool path.
• The Windows GPU runners come without an NVIDIA driver (nvcuda.dll is missing and
  cudaGetDeviceCount returns cudaErrorInsufficientDriver), so the job first installs the
  data-center driver that pytorch/pytorch's Windows CUDA smoke tests install
  (driver_update.bat, 580.88, from the same bucket); install_nvidia_driver_windows.ps1.
• et_cxx_test copies a test's runtime DLLs ($<TARGET_RUNTIME_DLLS>) beside it on Windows,
  which records no search path: the CUDA tests link extension_cuda.dll from another
  directory and could not start otherwise.

Test plan

• Windows 11, RTX 5080 (WDDM, memory pools supported), CUDA 13.0, llm-release-cuda with
  tests: all five runtime tests pass (test_cuda_allocator 16 passed, the no-pool test
  skipped as expected; mutable_state 15, weight_cache 11, guard 7, stream_guard 21).
• The no-pool path runs in the new Windows CI job on the A10G.
• Linux: the pool path is unchanged and covered by the existing unittest-cuda-runtime job.

Found while adding the Windows CUDA wheel (#23123), which needs this to run on the Windows
GPU runner; this PR does not depend on it.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/23405

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⏳ 1 Pending, 1 Unrelated Failure

As of commit 974d3f5 with merge base 5e21c13 ():

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• trunk / test-samsung-models-linux / linux-job (gh) (trunk failure)
  test_yolo26

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.