Fix Keyboard Manager editor file picker not opening when elevated

[niels9001]

Summary

Fixes #48845.

In the new WinUI 3 Keyboard Manager editor, clicking the browse icon to select a program path (or "start in" folder) for the Run Program action did nothing — no dialog appeared.

Root cause

The editor (PowerToys.KeyboardManagerEditorUI.exe) is launched by the Keyboard Manager module DLL via ShellExecuteExW from inside the PowerToys runner (src/modules/keyboardmanager/dll/dllmain.cpp). When PowerToys runs elevated, the editor inherits that elevation.

The browse buttons used the legacy Windows.Storage.Pickers (FileOpenPicker / FolderPicker + InitializeWithWindow). Those pickers activate through the UWP runtime broker, which fails with E_ACCESSDENIED in an elevated process. The handlers were async void with no try/catch, so the exception was swallowed and no dialog ever opened. Typing/pasting a path into the field still worked — matching the bug report.

Fix

Switch both handlers to the Windows App SDK Microsoft.Windows.Storage.Pickers API, constructed with a WindowId. Those pickers are a thin wrapper over the in-process Win32 Common Item Dialog (IFileOpenDialog, CLSCTX_INPROC_SERVER) and work correctly in elevated processes — the same mechanism already used elsewhere in PowerToys (e.g. Settings UI IFileDialog/GetOpenFileName, and CmdPal which already uses this exact namespace). Also wrapped the handlers in try/catch with Logger.LogError so any future failure is logged instead of silently swallowed.

Verification

• Built KeyboardManagerEditorUI.csproj (Release / x64) with all native dependencies — exit code 0.
• Confirmed against the Windows App SDK source that Microsoft.Windows.Storage.Pickers.FileOpenPicker uses create_instance<IFileOpenDialog>(CLSID_FileOpenDialog, CLSCTX_INPROC_SERVER) and dialog->Show(hwnd), i.e. the elevation-safe in-process dialog.

Notes / out of scope

The report also mentions some apps (e.g. visio.exe) not launching while others (winword.exe) do. That's a separate issue in the launch path (run_non_elevated uses CreateProcessW, which ignores registry App Paths / shell activation, unlike ShellExecute used by the Open URI action) and is not addressed here.