Replace deprecated FindCUDA module with find_package(CUDAToolkit) in Config.cmake.in

[joshkamm]

Context

Consumers of SlaterGPU's Config.cmake.in currently trip CMake policy CMP0146 during find_package:

CMake Warning (dev) at .pixi/envs/default/lib/cmake/SlaterGPU/SlaterGPUConfig.cmake:36 (find_package):
  Policy CMP0146 is not set: The FindCUDA module is removed.  Run "cmake
  --help-policy CMP0146" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

The FindCUDA module was deprecated in CMake 3.10 and removed in CMake 4.0 (which the current pixi env ships). Today it's only a dev-level warning, so it's invisible during normal builds. Once a CMake version that enforces CMP0146 strictly is in the build env, it'll become a hard configure-time error for every downstream consumer.

Where

SlaterGPUConfig.cmake.in:11-15:

# Find CUDA if available
find_package(CUDA QUIET)
if(CUDA_FOUND)
    enable_language(CUDA)
endif()

Suggested fix

Replace with the modern equivalent:

find_package(CUDAToolkit QUIET)

And expose CUDA::cudart / CUDA::cuda_driver as imported targets to consumers if any consumer-side linkage is actually needed. (Looking at the current state, the enable_language(CUDA) call may not even be necessary at consumer-side find_package time — consumers don't compile CUDA against SlaterGPU's headers; SlaterGPU's CUDA bits are baked into the installed .sos and .as already. Worth re-validating during the fix.)

Why now

• Adjacent to the recently-merged Drop consumer-side libcint pkg-config probe from Config.cmake.in #92 (Config.cmake.in cleanup) — same file, fresh context
• Closing soft-debt that's invisible today but becomes a hard breakage later
• Fits the umbrella "packaging discipline" thread tracked in ZimmermanGroup/XCtera#13

Out of scope

• Migrating SlaterGPU's own internal CMake (src/integrals/CMakeLists.txt etc.) off any deprecated CUDA APIs — those are build-side, not consumer-side, and a separate concern.