[Bug]: WSL backend never becomes ready on Node 22.16/22.17 - import.meta.main guard silently no-ops (engine range accepts broken versions)

[Qblaauw]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. In the WSL distro: nvm install 22.17.0 && nvm alias default 22.17.0 (any Node in [22.16.0, 22.18.0) reproduces)
2. Enable the WSL backend in T3 Code desktop and let it try to connect.
3. Watch ~/.t3/userdata/logs/server-child.log on Windows: start/exit pairs on every retry with code=0 and empty failure output; nothing ever listens on the backend port inside the distro.

Direct repro without the desktop app:

$ node --version
v22.17.0
$ node .../resources/app.asar.unpacked/apps/server/dist/bin.mjs --help
$ echo $?
0        # no output at all

Same command on Node 22.23.2 prints the CLI help, and the desktop backend then connects fine.

Expected behavior

Either of:

1. Engine range tightened to ^22.18 || ^23.11 || >=24.10 so ensure_remote_node_path rejects 22.16/22.17 and falls through to a working resolver (or surfaces the existing "install Node" error), or
2. Replace the import.meta.main guard with something version-agnostic (e.g. a process.argv[1] comparison), since bin.mjs is always invoked as an entrypoint.

A silent exit 0 is the worst failure mode here - the desktop log captures the child's output on failure, but there is nothing to capture. A one-line unsupported Node <version> on stderr would have made this a 5-minute diagnosis.

Actual behavior

"Connecting to WSL" spins forever (likely the same symptom as #5967 and #3709). The backend child exits 0 silently on every retry and never binds its port, so the readiness probe (GET http://<distro-ip>:<port>/.well-known/t3/environment) times out, the child is killed, and the spawn loop retries indefinitely.

Root cause: the server bundle's entrypoint guard is

if (import.meta.main) Command.run(cli, { version }).pipe(...)

import.meta.main was only added in Node 22.18.0 (and 24.2). On 22.16/22.17 it evaluates to undefined, so bin.mjs loads all its modules and then exits 0 with no output - it never runs the CLI, never reads the bootstrap envelope, never binds the port.

The engine range shipped in the runner script makes this worse, because it accepts the broken versions:

^22.16 || ^23.11 || >=24.10

Any Node in [22.16.0, 22.18.0) passes the engine check but cannot execute the entrypoint.

Impact

Blocks work completely

Version or commit

0.0.33

Environment

Windows 11 Pro 10.0.26200, T3 Code (Alpha) 0.0.33 desktop, WSL2 Ubuntu, Node v22.17.0 via nvm

Logs or stack traces

# ~/.t3/userdata/logs/server-child.log - every retry:
#   backend child started ... backend child exited code=0
#   (captured failure output: empty)

$ node --version
v22.17.0
$ node .../app.asar.unpacked/apps/server/dist/bin.mjs --help
$ echo $?
0

Screenshots, recordings, or supporting files

No response

Workaround

Upgrade the distro's default Node past 22.18: nvm install 22 (installed 22.23.2) + nvm alias default 22. Backend connects immediately afterwards.

Aside (will file separately if useful): on WSL the server runs directly from /mnt/c/.../app.asar.unpacked over 9p; a cold bin.mjs --help takes ~67s here (~14.7k files), exceeding the ~28s readiness window - so some WSL setups still can't connect even on a fixed Node until the bundle is staged onto the Linux filesystem (I bind-mount an ext4 mirror over that path as a workaround; related to #6311/#5876).