[Feature]: Let the WSL backend use a Node that is not on the distro's global login PATH

[oxionics-bodo-kaiser]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

I am using NixOS-WSL (but this applies to any linux distribution where one doesn't want to have a specific node version installed globally) and would like to use this as a backend for t3code which runs on Windows.

Proposed solution

An optional setting for an explicit Node executable to use for the WSL backend — e.g. wslNodePath, default
null. When set, preflight skips the login-shell discovery step and uses that binary directly (still applying
the existing engine-range check at DesktopWslEnvironment.ts:479-492, so a bad path fails loudly rather than
silently).

This fits the existing launch design without restructuring it: the launch already replays a nodePath and a
resolvedPath observed during preflight
(apps/desktop/src/backend/DesktopBackendConfiguration.ts:587-603), and derives the server's PATH from the
Node bin dir plus the login PATH. Pointing nodePath at a store path keeps npm/npx (same bin dir) and
git (login PATH) resolvable exactly as today.

Why this matters

It makes the WSL backend usable on declaratively-managed distros without asking the user to mutate their
system, and it costs the project no per-distribution knowledge — no apt/dnf/pacman/nix detection, no install
path, just one optional override.

Smallest useful scope

Having a config option for the custom node path would allow me to setup a sandbox with a certain node version

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.