Better handle remote linux-based OSs that do not follow FHS

• VSCode Version: 1.89.0
• Local OS Version: Windows 10 22H2
• Remote OS Version: NixOS master (2024-05-05)
• Remote Extension/Connection Type: ?

The upgrade from Remote-SSH v0.110.0 to v0.110.1 made it especially hard to use Remote-SSH with a NixOS remote host.

As background, the node binary that Remote-SSH downloads to the Linux host does not work on NixOS because NixOS does not have an FHS environment (i.e. with /usr/lib), so NixOS users must either patchelf or replace the node binary with one of the same major version.

With v0.110.0 (I think...) and earlier, if the node binary failed to run, the server downloader on the remote host would stop, vscode would pop up a modal error dialog, and NixOS users could run a script to replace the node binary.

With v0.110.1, if the node binary fails to run, the server downloader removes the ~/.vscode-server/cli/servers/Stable-b58957e67ee1e712cebf466b995adf4c5307b2bd.staging directory and tries to download again in an apparent infinite loop. This makes it much harder to patch or replace the node binary with one that works on NixOS. The infinite loop is bad for other reasons: with enough remote projects open, the repeated downloading can saturate a gigabit of downstream.

Steps to Reproduce:

1. Install Remote-SSH v0.110.1
2. Connect to a remote host running NixOS (any version)
3. Observe continuous failure to start node and nonstop downloading of the server component

Start by reproducing the Remote-SSH v0.110.1 connection against a NixOS host and inspect the server downloader behavior around the failing node binary and the ~/.vscode-server/cli/servers/...staging directory. Done means a failed node launch does not trigger an apparent infinite download loop and the existing recovery workflow remains usable.