Add Windows arm64 discovery for cuDLA

[nikshayshrivastava]

Description

Adds Windows (arm64) support for cuda.bindings.cudla, which was
previously available only on Linux/aarch64 (Tegra).Changes:

• Add Windows discovery for the cuDLA runtime in pathfinder's descriptor
  catalog so load_nvidia_dynamic_lib("cudla") can locate cudla.dll
• Relax test_supported_libnames_windows_site_packages_libdirs_ctk_consistency
  to a subset check: every site-packages entry must map to a supported Windows
  libname, but a supported library may legitimately omit site_packages_windows
  (as cuDLA now does).

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

Needs-Restricted-Paths-Review was assigned by CI: Restricted Paths Guard.

For details, open this workflow run and click Summary.

For external contributors: thank you for your interest in improving CUDA Python. The cuda_bindings/ package is distributed under the NVIDIA Software License, which does not allow us to accept external contributions to files under cuda_bindings/ in this repository.

Please close this PR. If your changes also include updates outside cuda_bindings/, please open a new PR containing only those changes so we can review them separately under the applicable license.

If you are an NVIDIA employee and believe this label was applied in error, no action is needed; a maintainer will review and remove the label if appropriate.

[leofang]

I wonder why the path alarm CI would trigger for Nikshay... 🤔

[rwgk]

I wonder why the path alarm CI would trigger for Nikshay... 🤔

Collaborator permission: read

is not a trust signal because any github member has read access to this public repo.

For Author association we could have:

• OWNER: owns the repository
• MEMBER: member of the org that owns the repository
• COLLABORATOR: invited collaborator on the repository
• CONTRIBUTOR: previously committed to the repository
• NONE: no detected association with the repository

With authenticated gh I can determine conclusively that Nikshay is a MEMBER, but unfortunately for our purposes, CONTRIBUTOR clobbers that. — That clobbering behavior could be non-deterministic, although I don't have enough evidence to be sure.

Bottom line: we don't get a lot of false positives, but this is one. Unfortunately I don't have new ideas; we explored a lot already (#2104).

[rwgk]

This looks good, but did we ever test real cuDLA API calls through cuda.bindings.cudla on WoA?

The cuda_bindings unit tests import the module and check enums/POD/API surface, but they don't call wrappers that trigger the lazy _init_cudla() path. That's not different from Linux coverage on the available GHA runners here, but we do have internal Orin testing that exercises _init_cudla() against real libcudla.so.

The WoA evidence so far shows that pathfinder can locate cudla.dll, which is useful, but I'd feel much more comfortable merging this PR if we had at least internal evidence that the Windows binding loader path has coverage comparable to the Orin testing.

@isVoid could you maybe work with @nikshayshrivastava on more complete WoA testing.

[rwgk]

Nit: the explicit assertion message after the comma can be dropped. We already run pytest with --showlocals, so site_packages_libnames and supported_libnames will be shown on failure, and pytest’s set assertion introspection should show the subset mismatch.