fix(pi): run PATH installation correctly through WSL

[CamAnNguyen]

Problem

On Windows with Use WSL enabled, Jean could not use an existing PI installation from the selected distro. A typical working installation looked like:

/home/linuxbrew/.linuxbrew/bin/pi   -> PI 0.84.1
/home/linuxbrew/.linuxbrew/bin/node -> Node 25.3.0

Jean still reported PI not found in System PATH. Choosing Install now could instead report:

Failed to run npm install for PI: program not found

The machine did not lack PI, Node, or npm. The failures came from crossing the Windows/WSL boundary inconsistently.

Root cause

1. PI discovery queried the selected WSL distro, but status/model/chat code later used native Windows Path::exists() on Linux paths such as /home/linuxbrew/.linuxbrew/bin/pi.
2. WSL execution did not load the user's login environment. An npm shim with #!/usr/bin/env node could therefore resolve WSL's old /usr/bin/node instead of the matching Linuxbrew/nvm/bun runtime.
3. Authentication checked the Windows home and process environment rather than the selected distro's ~/.pi/agent/auth.json and provider variables.
4. Package-manager detection attempted Windows filesystem canonicalization for Linux paths.
5. PI's WSL fallback could become bare pi instead of retaining the absolute path found by wsl_which().

Solution

• resolve PI through wsl_which() and retain the absolute Linux executable path

• use resolved_cli_exists() so Linux executables are checked inside the selected distro

• launch resolved WSL PI commands as:

  wsl.exe -d <distro> --cd <translated-cwd> --exec \
    bash -lc 'exec "$@"' jean-cli <absolute-pi-path> <pi-args...>
  

• pass the executable and PI arguments as positional parameters, preventing shell interpolation of prompts, paths, model IDs, quotes, metacharacters, or multiline values

• use the login environment consistently for status, model listing, one-shot execution, normal chat execution, and provider keys

• check PI authentication inside the selected distro

• use WSL-aware Linuxbrew/npm/bun package-manager detection

Native Windows behavior remains unchanged when WSL is disabled.

Additional production-build repair

A pre-existing duplicate diagnostics field in jean-core/src/chat/antigravity.rs prevented Rust/Tauri production compilation with E0062. The duplicate initializer was removed in this PR so the Windows production build can complete.

Validation

Rust tests

• cargo test --manifest-path jean-core/Cargo.toml platform::wsl::tests --lib — 31 passed
• cargo test --manifest-path jean-core/Cargo.toml pi_cli::commands::tests --lib — 3 passed
• cargo test --manifest-path jean-core/Cargo.toml chat::pi::tests --lib — 19 passed

Real Windows → WSL smoke tests

Using Ubuntu-22.04 and Linuxbrew:

• resolved /home/linuxbrew/.linuxbrew/bin/pi
• pi --version returned 0.84.1
• pi --list-models completed successfully
• WSL authentication detection found distro credentials
• argument round-trip preserved spaces, both quote styles, $HOME, $(uname), globs, and multiline values without expansion

Frontend

The reported Pierre TypeScript errors came from stale local dependencies: node_modules contained @pierre/diffs@1.0.11, while package.json and bun.lock require 1.3.2.

After:

bun install --frozen-lockfile

validation passed:

• bun run typecheck — passed
• bun run build — passed

No dependency or frontend source change was required; the manifest and lockfile were already correct.

Windows Tauri production build

With the MSVC linker selected explicitly because Git's unrelated link.exe shadows it in this shell:

• frontend production build — passed
• Rust release compilation — passed
• application generated at src-tauri/target/release/jean.exe
• MSI generated: Jean_0.1.73_x64_en-US.msi
• NSIS generated: Jean_0.1.73_x64-setup.exe

The command then stopped only at updater signing because this local environment does not have TAURI_SIGNING_PRIVATE_KEY. Compilation and both Windows installer bundles completed successfully.

Scope note

WSL custom-provider models.json storage remains host-home based. That is a separate pre-existing integration gap and is not required for using an already installed/authenticated WSL PI through System PATH.