Desired Processing version not found on Windows despite install-locator correctly detecting the installation

[willbegreat-netizen]

Environment

• OS: Windows 10/11
• Extension version: 1.1.7
• Processing version: 4.5.6
• Install path: C:\Program Files\Processing\Processing.exe

Problem

The extension reports:
"Desired Processing version not found, please install Processing 4.5.6
and open it at least once. Found versions: 4.5.6"

This happens even though Processing 4.5.6 is correctly installed, has
been run manually multiple times, and preferences.txt exists under
%APPDATA%\Processing.

Root cause found

1. Running the extension's own install-locator directly confirms it
   correctly finds the installation:

   .\install-locator-win32\bin\install-locator.bat
   [C:\Program Files\Processing\Processing.exe^4.5.6]

2. The issue is in the subsequent version-check step in
   client/out/setupSelectedVersion.js, which does:

   const version = execSync("${app.path}" --version, { encoding: 'utf-8' });
   if (!version || !version.includes(app.version)) { ... fail ... }

3. On Windows, running Processing.exe --version directly does NOT
   print a version string to stdout. Instead it launches the full
   Processing IDE GUI (confirmed via Get-Process — three Processing.exe
   processes appear after running --version, matching a normal launch).

   This is consistent with Processing's Windows binary being a jpackage
   GUI-subsystem launcher (built without --win-console), which means
   it never attaches to the caller's console and does not treat
   --version as a CLI flag at all — it just launches the GUI.

4. As a result, execSync() always returns an empty string on Windows,
   the version check always fails, and the extension reports the
   installation as "not found" even when install-locator found it
   correctly.

Suggested fix directions

• Don't rely on Processing.exe --version for validation on Windows;
  trust the version already reported by install-locator instead, or
• If a console-mode verification is still needed, check whether a
  separate console-subsystem binary (like the old processing-java.exe
  from Processing 3.x) still exists in newer installs, or
• At minimum, guard against launching the GUI unintentionally when
  probing for --version.

Reproduction

1. Install Processing 4.5.6, run it once.
2. Open a JS/non-Processing project in VS Code with the extension active.
3. Observe the error, or run the extension's own install-locator to
   confirm it detects the install correctly.
4. Run & "C:\Program Files\Processing\Processing.exe" --version and
   observe that it launches the GUI instead of printing a version string
   (verify with Get-Process — multiple Processing.exe processes appear).

Possibly related: unusual portable-settings path in Language Server log

While investigating, the following was also observed repeatedly in the
Processing Language Server output:

Looking for portable settings at:
C:\Program Files\Processing\Processing.exe\preferences.txt

This path is malformed — Processing.exe is a file, not a directory, so
this path can never resolve. This suggests some part of the extension
(or its Language Server) may be concatenating the executable path
directly with "preferences.txt" instead of using its parent directory.

I'm not certain whether this is the same root cause as the --version
issue above or a separate bug in the portable-settings detection path,
but flagging it here since both appeared in the same environment and
both relate to how the extension resolves paths around Processing.exe.