refactor(pathfinder): author candidates in search order

[rwgk]

Description

Follow-up to #2689 and the ordering discussion in
#2689 (comment).

Pathfinder historically authored dynamic-library filenames in ascending order,
then reversed them at each runtime lookup site. That distinction no longer
serves the descriptor catalog and makes preference mistakes easier.

This PR:

• authors Linux SONAMEs and Windows DLL names directly in runtime preference
  order, most preferred first;
• makes filesystem discovery, already-loaded detection, and native loader
  search consume the descriptor tuples as-is;
• preserves the historical order of the private legacy SUPPORTED_*
  projections at their compatibility boundary; and
• documents that ordered candidates for dynamic libraries, headers, binary
  utilities, static libraries, and bitcode libraries are consumed first to
  last.

The tuple rewrite is mechanically behavior-neutral: every multi-name dynamic
library tuple is the exact reverse of its previous catalog representation, and
the corresponding runtime reversal is removed.

Validation

• New or existing tests cover these changes.
• The documentation is up to date with these changes.
• Full cuda-pathfinder suite: 1,608 passed, 5 skipped on CUDA 13.3.
• Repository-wide pre-commit suite (excluding the network-only link
  checker).

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

/ok to test e7705a7

[isVoid]

Just confirming one thing below, else lgtm.

[isVoid]

I think the order of libnames are actually non-essential here, is that correct? Not a change request, just confirming my thoughts. I see that the only place uses the global variable is here and this test. And neither depend on the order, actually, they use set-like operation at either places.

[rwgk]

Yes, that is correct. There are a few additional in-tree uses of these mappings, but they are all order-insensitive: they use dictionary keys, membership, parametrization, or uniqueness checks. Runtime discovery and loading consume the descriptor tuples directly.

The reversal here is deliberately conservative. supported_nvidia_libs.py is retained for legacy compatibility, and although these constants are private implementation details, client code could have imported and iterated, indexed, or compared their tuple values. Preserving their historical order costs only this small conversion and keeps the refactor mechanically strictly behavior-neutral.

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.