cuda_toolkit check fails with ModuleNotFoundError: No module named 'cuda.core.system'

[mmccarty]

Summary

The `cuda_toolkit` check added in #141 imports `from cuda.core.system import get_driver_version` in `_gather_toolkit_info` (cuda_toolkit.py:161). That submodule is not present in `cuda-core 0.3.2`, so the check raises `ModuleNotFoundError` at runtime on environments pinned to that version.

`cuda-core` is a transitive dependency of `cuda-pathfinder` rather than a direct declared dependency of `rapids-cli`, so environments can end up with older `cuda-core` releases that don't expose `cuda.core.system`.

Repro

```console
$ rapids doctor --verbose
...
cuda_toolkit_check failed
No module named 'cuda.core.system'
```

Full traceback:

```
File "rapids_cli/doctor/checks/cuda_toolkit.py", line 161, in _gather_toolkit_info
from cuda.core.system import get_driver_version
ModuleNotFoundError: No module named 'cuda.core.system'
```

Environment

• `cuda-core` 0.3.2 (installed; `cuda.core` is importable but has no `system` submodule)
• Python 3.13
• Linux

Suggested fixes

• Add `cuda-core` (with an appropriate minimum version that exposes `cuda.core.system.get_driver_version`) as an explicit dependency in `dependencies.yaml` / `pyproject.toml`.
• Alternatively, fall back to `pynvml.nvmlSystemGetCudaDriverVersion` (already used elsewhere in `rapids_cli`) when `cuda.core.system` isn't available, so the toolkit check degrades gracefully on older `cuda-core`.

Found while end-to-end testing #137 on a real GPU host.

[mmccarty]

Closing — this isn't actually a declaration bug. On further investigation:

• cuda-core >=0.6.0 is already declared in dependencies.yaml and propagates to pyproject.toml via rapids-dependency-file-generator. cuda.core.system became a proper submodule in cuda-core 0.6.0, so the declared constraint matches the import the code performs.
• The failure I hit was in an older rapids-26.02 conda environment with cuda-core 0.3.2 that conda had pinned due to other RAPIDS packages. A fresh conda environment resolving against the current constraints picks up cuda-core >=0.6.0 and the check works as intended.

Not worth a code change. Anyone hitting ModuleNotFoundError: No module named 'cuda.core.system' should recreate their environment.