[FEA]: Explore pathfinder "scoped search" feature

[rwgk]

Problem to solve

The searches implemented in load_nvidia_dynamic_lib() and find_nvidia_header_directory() are completely independent from each other. For example, load_nvidia_dynamic_lib("nvrtc") might resolve to a site-packages path, while load_nvidia_dynamic_lib("nvJitLink") finds a Conda path, and find_nvidia_header_directory("nvvm") locates headers under /usr/local/cuda. This can lead to surprising inconsistencies and confusing behavior deep in the call stack.

Potential approach (with low maintenance as a goal in mind)

Core idea: Introduce the concept of a pivot library that defines the scope for all subsequent searches.

Here, package system means, for example:

• /usr/local/cuda (or another "standard" CTK installation)
• Conda (including pixi)
• site-packages (wheels, PyPI)

How it would work in practice:

• A client code author decides which library is most pivotal and loads it first.

• search_scope = cuda.pathfinder.determine_search_scope(pivot_libname="nvrtc") — Loads the pivot library and returns it in a wrapper object.

• loaded_dl = search_scope.load_nvidia_dynamic_lib("nvJitLink") — Only succeeds if the target library exists in the same package system, otherwise fails with a helpful error.

• hdr_dir = search_scope.find_nvidia_header_directory("nvvm") — Similarly constrained to the same package system.

This design shifts responsibility for consistency to package managers, which already provide version alignment via pinning. We avoid duplicating those mechanisms and instead ensure our tooling surfaces clear, consistent results.

[rwgk]

xref to #1090 (comment)

Comment by @kkraus14 there:

If one library has a binary dependency on another library, I don't think compatibility guarantees are made outside of driver version. I.e. lib2 depends on lib1, the only guarantee we currently have is that it works if both lib2 and lib1 are the same patch version. So from the perspective of test_load_nvidia_dynamic_libs.py we could end up in an environment with different patch versions and someone blows up at load time because we load an incompatible dependency (since the dependencies aren't captured in python package dependencies to support using a system CTK).

Cross-referencing here since this might be something we could guard against (e.g. helpful error message) as part of the scoped search feature.