fix(lsp,dap): resolve program names via PATHEXT before spawning

[rwetz]

The bug

Installing vscode-langservers-extracted gave Nexis a working CSS/HTML/JSON language server that it still refused to start, and the missing-tools notice told the story backwards: pressing refresh cleared the entry, then opening a .css file put it straight back.

The two sides were asking different questions.

• tool_probe (src-tauri/src/modules/tools.rs) walks PATHEXT on Windows on purpose — 1.25.0 added that precisely because these servers land as .cmd shims.
• LspSession::start handed the bare name to proc::command, and Rust's Windows program resolution appends only .exe; it never consults PATHEXT.

So vscode-css-language-server resolved for the probe and did not exist for the spawn.

The fix

The PATH walk now returns the resolved path instead of a bool:

pub fn resolve_on_host(binary: &str) -> Option<PathBuf>
fn resolves_on_host(binary: &str) -> bool { resolve_on_host(binary).is_some() }

Both the LSP and DAP clients resolve first and spawn that path. One walk answers "is it installed?" and "what do I spawn?", so the two cannot drift apart again. When resolution finds nothing the bare name is still passed through, leaving the failure path and its error message unchanged.

The part that matters more than the original diagnosis

PATHEXT spellings are now tried before the extensionless one. npm's shim writer emits three files per bin — foo.cmd, foo.ps1, and an extensionless foo that is a bash script for MSYS/Git Bash. The old suffix list put the extensionless spelling first, which was harmless for a boolean probe but would have made the resolver return a path CreateProcessW cannot execute — converting a lookup miss into a spawn failure.

Trying PATHEXT first selects the .cmd, which Rust's std routes through cmd.exe with the hardened quoting added for CVE-2024-24576. No hand-rolled cmd /c.

Why DAP is in scope

Not pre-emptive: the adapter command is free text in the debugger panel, so anyone naming an npm-installed adapter (js-debug-adapter) hits the identical gap.

ml.rs and python.rs are deliberately untouched — they spawn interpreters and absolute paths, not npm shims.

Verification

Passing locally on Linux:

• cargo test — 195 lib + 11 pitfall tripwire tests
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --check — clean
• src/lib/pitfall-guards.test.ts — 16 passed

Known gap: the Windows branch is #[cfg(windows)], so CI on Linux never compiles it. Its body was type-checked and run standalone (yields [".COM", ".EXE", ".BAT", ".CMD", ""], the ordering the fix depends on), and windows_tries_pathext_before_the_extensionless_name asserts the ordering invariant on every platform by checking the suffix list's shape. The actual spawn of a .cmd shim is unverified until this runs on Windows — rebuild, open a .css file, confirm the missing-tools pill stays clear instead of reappearing.

Also included

• CHANGELOG entry under [Unreleased] / Fixed.
• docs/vault/decisions/program-resolution-before-spawn.md recording the PATHEXT/Command asymmetry, the alternatives rejected, and why resolution lives in the callers rather than in proc::command.
• Fixed a stale line in docs/vault/Home.md that claimed decisions/ was empty; two notes already existed.

🤖 Generated with Claude Code