fix: guard HIP_PATH and VULKAN_SDK dirs with os.path.exists before add_dll_directory

[emptyngton]

Problem

On Windows, os.add_dll_directory() raises FileNotFoundError: [WinError 3] when the path does not exist. In llama_cpp/_ctypes_extensions.py, the HIP_PATH and VULKAN_SDK branches pass their sub-directories straight to os.add_dll_directory() without checking that they exist.

The result: a single stale environment variable — left behind by an SDK the user uninstalled, upgraded, or moved — makes import llama_cpp fail outright, even though the backend in question isn't used at all. A CUDA build dies because of a leftover Vulkan variable.

Reported by a user running a CUDA (cu128) wheel who had a leftover VULKAN_SDK pointing at a deleted folder:

FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\VulkanSDK\1.4.350.0\Bin'

Minimal repro on any Windows box:

import os
os.environ["VULKAN_SDK"] = r"C:\VulkanSDK\1.4.350.0"  # any non-existent path
import llama_cpp  # FileNotFoundError [WinError 3]

Because it fires during module import, the traceback points at the loader rather than the user's environment, so it tends to get reported as a broken wheel or a broken install.

Solution

Apply the pattern the CUDA_PATH branch directly above already uses: build each candidate path, and only call os.add_dll_directory() when os.path.exists() is true.

This also handles partially-removed SDKs gracefully — each directory is tested individually, so if only bin survives it still gets added instead of the whole import raising.

No behaviour change for users with a valid SDK: every directory that exists today is still registered.

Notes

• Same three-line pattern as the existing CUDA_PATH block, kept stylistically consistent with it.
• Verified against: stale root (nothing added, no raise), valid SDK (both dirs added), partially-removed SDK (surviving dir added), variable unset (no-op).
• The HIP_PATH branch has the identical issue and is fixed the same way.

[JamePeng]

LGTM