spawned LSP server child process inherits mcpls's full environment

[bug-ops]

Description

lsp/lifecycle.rs:232 spawns the configured LSP server command via Command::new with no env_clear(). The child process inherits mcpls's full environment, including any secrets or tokens present in the host process's environment (agent tokens, ZEPH_*-style vault-injected keys, etc.).

For a trusted server config this is harmless (the user chose to run that command). But it's what turns an untrusted command into a data-exfiltration vector rather than just an arbitrary-exec vector, and it means even a trusted-but-compromised or misconfigured server binary can read environment secrets it has no need for.

Reproduction Steps

1. Set an environment variable containing a secret before starting mcpls (e.g. MY_SECRET=xxx).
2. Configure any [[lsp_servers]] entry with a command that dumps its environment (e.g. env or a wrapper script).
3. Start mcpls; observe the spawned process's environment includes MY_SECRET.

Expected Behavior

The spawned LSP server process receives only the environment variables it actually needs (e.g. PATH, and any explicitly configured env entries once #env is wired up) rather than mcpls's full environment.

Actual Behavior

Command::new with no env_clear() — full environment inheritance.

Environment

• Version: current main
• File: crates/mcpls-core/src/lsp/lifecycle.rs:232

Logs / Evidence

Flagged during the security-audit re-verification pass for PR #245 (fix for #229): "no env_clear(), so the child inherits mcpls's full environment (agent tokens, ZEPH_*, etc.). Harmless for trusted servers, but it is what turns an untrusted command into data exfiltration."