On Windows, CoreTools.Which searched Environment.CurrentDirectory before
any PATH entry, and blank, quoted-empty or relative PATH entries also
resolved against the current directory. Starting UniGetUI from a folder
holding a planted gsudo.exe, winget.exe, choco.exe or python.exe made
that file win over the real one. This was the root of the gsudo concern
on the elevator fallback, and it still applied to the ForceUserGSudo
opt-in and to every manager executable lookup. The search now covers only
fully qualified PATH entries.

The Windows elevator decision moves into ResolveWindowsElevatorPathAsync,
which takes the executable directory and the two gsudo switches as
inputs. The release no-fallback guarantee is no longer hidden behind
#if !DEBUG and is now covered by tests. The DEBUG branch also stops
logging "Using system GSudo" when gsudo is not installed.

The parent-directory lookup in ResolveBundledElevatorPath is kept: #4719
added it for the nested publish layout. Its parent is admin-only on a
Program Files install, and on a user-writable install whoever can plant
there can already replace UniGetUI.exe. The Linux sudo/pkexec/SSH_ASKPASS
resolution is unchanged for the same reason: PATH and environment are the
user's own, and a fixed /usr/bin path would break NixOS's
/run/wrappers/bin/sudo.