fix(cdi): include 32-bit libraries in discovery

[elibosley]

Summary

CDI generation omitted the host's 32-bit NVIDIA driver stack on multilib systems; this combines predefined-path and linker-cache discovery so generated specs include both native and compat32 libraries.

Why This Exists

ldcache.List() returns separate 32-bit and 64-bit library sets, but the CDI lookup path discarded the 32-bit set. The default library locator also stopped after finding libraries in a predefined native path, which prevented the linker cache from contributing libraries installed in a separate compat32 directory.

The resulting CDI spec could expose the 64-bit NVIDIA stack while leaving a 32-bit Vulkan application such as a Steam or Proton title without the matching vendor libraries. In that state, the application can select software rendering even though compatible ELF32 NVIDIA libraries are installed on the host.

This is related to #563, which tracks broader graphics-library coverage.

Resolution

The default library locator now merges predefined-path and linker-cache results and deduplicates the combined list. Linker-cache discovery consumes both architecture lists, with native libraries first so existing version-inference precedence remains stable.

This keeps architecture discovery in the host linker cache rather than adding distribution-specific compat32 paths to CDI generation.

Reviewer Considerations

• Please confirm that an exported lookup.Merge combinator is the preferred shape for combining locator results; it mirrors the existing exported lookup.First behavior while retaining successful matches when another locator fails.
• The default locator now returns all unique matches instead of the first successful source. This is intentional because CDI needs every driver-library directory, but callers that infer a driver version still see native libraries first.
• Multilib hosts will generate larger CDI specs because valid ELF32 driver libraries are now included. Hosts without 32-bit linker-cache entries should be unchanged.
• This PR is limited to discovery and regression coverage. It does not add distribution-specific paths or modify runtime selection policy.

Behavior Changes

• CDI specs generated on multilib hosts include matching 32-bit NVIDIA driver libraries exposed through the host linker cache.
• Native library ordering is preserved for callers that use the first match.
• Duplicate paths found through predefined directories and the linker cache are emitted once.

Implementation Summary

• Consume both values returned by ldcache.List().
• Add a locator combinator that merges successful results across lookup sources.
• Use the merged, unique locator for default library discovery.
• Add regression tests for mixed 32-bit/64-bit linker-cache entries, ordering, result merging, and partial lookup failure.

Verification

• make test passed.
• go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest run --timeout 5m ./... passed with 0 issues.
• go vet ./pkg/lookup passed.
• git diff --check passed.
• Real-host comparison on an x86_64 linux-based system with NVIDIA 595.84:
  • toolkit 1.19.1 generated 40 /usr/lib64 library mounts and 0 /usr/lib library mounts;
  • patched main generated 41 /usr/lib64 library mounts and 25 /usr/lib library mounts;
  • the newly discovered /usr/lib entries were verified as ELF32 and included libcuda, libnvidia-ml, and libGLX_nvidia.
• The host's live CDI specification was not replaced during validation.
• The commit has a matching DCO sign-off and a GitHub-verified SSH signature.

Risk

Low to moderate. The discovery set intentionally grows on multilib hosts, and the primary compatibility risk is a caller assuming only one architecture is returned. Native-first ordering, deduplication, package tests, the full upstream test suite, and real-host CDI generation cover that behavior.

[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.