* refactor(process): give POSIX PATH search order one owner
Program lookup, the packet-tool locator and Jadx's Java lookup each split
PATH and resolved empty and relative entries themselves. They now take the
candidates from posixPathCandidates in src/process/executableSearch and keep
only their own probe and failure reporting. A counted architecture guard
keeps new PATH splits from returning; the remaining Windows and Ghidra
searches are baselined.
* refactor(process): move the colon-split PATH searches onto the search owner
REA's launcher-alias lookup and Ghidra's macOS Java lookup split PATH on
":" and skipped relative entries themselves; they now use
posixPathCandidates with relativeEntries: "skip", and the guard counts
colon splits of PATH as well.
* fix(process): produce PATH candidates lazily so an unused entry cannot fail an earlier match
* refactor(process): give Windows PATH/PATHEXT search order the executable search owner (#10916)
* refactor(process): give Windows PATH/PATHEXT search order the executable search owner
* fix(process): keep later PATH entries searchable after a stray quote or a removed working directory
* fix(reverse): refuse a Windows objdump or Rizin command that PATH does not find (#10953)
* fix(reverse): refuse an objdump or Rizin command Windows PATH does not find instead of launching the bare name
* fix(reverse): report a Windows lookup refusal after cancellation and to capability discovery
* fix(desktop): search a Windows host's PATH as Windows does when doctor looks up a program
programOnPath sent every host through the POSIX PATH search, so on Windows a
relative PATH entry reached absoluteCallerPath with platform linux and the
Windows working directory, which resolved against itself until the stack
overflowed. programOnPath now searches PATH and PATHEXT through
windowsPathCandidates on a Windows host, and absoluteCallerPath refuses a
non-POSIX working directory with a TypeError instead of recursing.