native_menu: Constrain uxtheme loading to System32

[lurenjia534]

Description

Opening a native menu on Windows initializes optional dark-mode APIs by loading
uxtheme.dll. The previous implementation passed only the DLL name to
LoadLibraryW, allowing the normal DLL search order to consider a file beside
the application executable before the System32 copy. Under the required loader
conditions, a locally planted DLL could execute code from DllMain when a user
opened a native menu or input context menu.

This change uses LoadLibraryExW with LOAD_LIBRARY_SEARCH_SYSTEM32, restricting
the lookup to the operating-system copy. Ordinal resolution, module caching, and
the existing fallback when the optional APIs are unavailable remain unchanged.

Before and after

	Before this fix	After this fix
Loader call	LoadLibraryW(L"uxtheme.dll")	LoadLibraryExW(..., LOAD_LIBRARY_SEARCH_SYSTEM32)
Search behavior	The default DLL search order could select an application-directory DLL	Directory searches for this load are restricted to System32
Security result	A planted DLL could execute DllMain in the application process	The same planted DLL is ignored
Wine dynamic result	Application-directory uxtheme.dll loaded; payload exited with code 77	System32 uxtheme.dll loaded; program exited normally with code 42
Menu fallback	Normal system menu when loading or symbol lookup fails	Unchanged

Windows CI passed for this commit. The before/after loader check was performed
under Wine, not native Windows. A native Windows smoke test for light/dark native
menus and input context menus is still pending.

Security impact

This closes the reported application-directory DLL planting path for
uxtheme.dll. Exploitation previously required Windows, a consuming application
that uses the native-menu implementation, permission to plant a DLL in an early
search location, and a loader state in which the genuine module was not already
selected.

Suggested severity: medium. Successful exploitation could run native code
with the application's privileges, while the prerequisites are local and
environment-dependent.

Implementation

- LoadLibraryW(windows::core::w!("uxtheme.dll"))
+ LoadLibraryExW(
+     windows::core::w!("uxtheme.dll"),
+     HANDLE::default(),
+     LOAD_LIBRARY_SEARCH_SYSTEM32,
+ )

A short source comment records the security reason for retaining the constrained
search policy.

How to test

1. Build a minimal Windows executable that loads uxtheme.dll using the old
   bare-name call.
2. Place a test uxtheme.dll beside the executable. Its DllMain should exit
   with a unique code such as 77, and it should export ordinals 133, 135, and
   136.
3. Launch the executable from a different working directory. Confirm the planted
   application-directory DLL loads and the process exits with code 77.
4. Rebuild the executable with the patched LoadLibraryExW call and leave the
   same planted DLL in place.
5. Confirm the loader resolves the System32 DLL and the planted DLL does not run.
6. On Windows, open native menus in both light and dark themes and open an input
   context menu with the right mouse button. Confirm the menus render and their
   actions still dispatch normally.

Validation performed

• cargo fmt --all -- --check
• git diff --check
• Patch reverse-check confirms the supplied patch was applied exactly
• Patched call compiled for x86_64-pc-windows-msvc against the repository's
  windows 0.58.0 API in an isolated check crate
• Wine 11.16 before/after test with the same planted DLL and no DLL override:
  before loaded the application-directory DLL and exited 77; after loaded
  the System32 DLL and exited 42
• Full cargo test on windows-latest
• Native Windows light/dark and input context-menu smoke test

The repository's accessibility-driven UI procedure is macOS-specific and cannot
exercise this cfg(target_os = "windows") load path. This change does not alter
the intended menu interaction or appearance; the pending native Windows smoke
test covers the affected platform behavior.

The full workspace cross-check could not complete on the Linux host because the
gpui-pre Windows resource build expects the native MSVC/Windows resource
environment. It failed in that dependency's build script before checking this
crate; the isolated Windows-target API check passed.

Breaking changes

None.

Checklist

• Read CONTRIBUTING.md and followed the existing Windows code style.
• Kept the implementation to one security fix in one source file.
• Human reviewer confirmed the AI-assisted code and report are accurate.
• Windows GitHub Actions passed.
• Native Windows menu behavior was smoke-tested.

[huacnlee]

Thanks