[Bug]: Windows CLI inherits a stale Crashpad pipe and logs an error on every command

### Environment

- Windows 11, build 10.0.26200; PowerShell 7.6.5.
- Packaged Orca CLI and desktop runtime **1.4.198**; runtime remained `ready` throughout.
- Commands run from an Orca-managed Codex terminal (codex-cli 0.153.4).
- Source inspected at tag `v1.4.198`, commit `36b992b862c1c43eddab6cb5fa7bb2f69cc1f697`.

### Summary

An inherited `CHROME_CRASHPAD_PIPE_NAME` pointing to an unavailable pipe makes the packaged Windows CLI emit a Chromium Crashpad error on every invocation. The CLI operation itself succeeds. Clearing only that variable in the calling test process removes the error; restoring its original value brings it back.

### Steps to reproduce

1. In an affected Orca-managed terminal, confirm `CHROME_CRASHPAD_PIPE_NAME` is present. No value needs to be disclosed.
2. Run `orca status --json`, capturing stdout and stderr separately. Repeat three times.
3. Save the variable, temporarily remove it from this shell's process environment, and repeat the same command three times.
4. Restore the original value and repeat three more times.

PowerShell comparison (process-local environment only):

```powershell
$savedPipe = [Environment]::GetEnvironmentVariable('CHROME_CRASHPAD_PIPE_NAME')
try {
orca status --json 1> inherited.json 2> inherited.stderr.txt
[Environment]::SetEnvironmentVariable('CHROME_CRASHPAD_PIPE_NAME', $null)
orca status --json 1> cleared.json 2> cleared.stderr.txt
[Environment]::SetEnvironmentVariable('CHROME_CRASHPAD_PIPE_NAME', $savedPipe)
orca status --json 1> restored.json 2> restored.stderr.txt
} finally {
[Environment]::SetEnvironmentVariable('CHROME_CRASHPAD_PIPE_NAME', $savedPipe)
}
```

### Expected

A successful CLI query should not try to register against a stale crash-reporting channel inherited from its parent and print an unrelated native error.

### Actual: live A/B/A reproduction on September 9, 2026

```text
mode attempt exit runtime stderrBytes
inherited 1 0 ready 169
inherited 2 0 ready 169
inherited 3 0 ready 169
cleared 1 0 ready 0
cleared 2 0 ready 0
cleared 3 0 ready 0
restored 1 0 ready 169
restored 2 0 ready 169
restored 3 0 ready 169
```

Exact stderr from one attempt:

```text
[0909/190714.326:ERROR:third_party\crashpad\crashpad\util\win\registration_protocol_win.cc:108] CreateFile: O sistema não pode encontrar o arquivo especificado. (0x2)
```

The Portuguese OS text means the specified file cannot be found. Stdout remained one valid JSON document, with `ok: true` and `result.runtime.state: "ready"`. This is **not** a claim that stdout JSON is corrupt or that the runtime is unavailable. Merging stderr into a JSON parser is separately unsupported; the defect here is the repeated irrelevant diagnostic.

The same error also appeared on `orca --version`, `skills get`, `terminal create`, and orchestration calls in this session. The controlled counts above are specifically for `status --json`.

### Where in the code

[`native/windows-cli-launcher/OrcaCliLauncher.cs:37-50`](https://github.com/stablyai/orca/blob/36b992b862c1c43eddab6cb5fa7bb2f69cc1f697/native/windows-cli-launcher/OrcaCliLauncher.cs#L37-L50) creates `ProcessStartInfo` for the packaged Electron executable, preserves the inherited environment, moves the Node variables, and sets `ELECTRON_RUN_AS_NODE=1`. It does not remove `CHROME_CRASHPAD_PIPE_NAME` before launching the CLI child. The A/B/A test isolates that inherited variable as the trigger for the native diagnostic; it does not establish which earlier process originally made the pipe stale.

PR #16963 is related to Chromium descriptor/handle inheritance, but describes a daemon spawn-path change with the environment contract unchanged. This report is specifically about an inherited environment variable reaching the short-lived packaged CLI. I found no issue/PR for `CHROME_CRASHPAD_PIPE_NAME` or `registration_protocol_win` in the repository search; the Crashpad discussion search was also empty.

### Impact on multi-agent orchestration

Every CLI query and lifecycle call adds the same native error to agent-visible logs, obscuring actionable failures and multiplying noise in long-running coordination. A temporary process-local environment cleanup demonstrated the cause without restarting Orca, changing settings, or interrupting any existing workers.

Start in native/windows-cli-launcher/OrcaCliLauncher.cs:37-50 and inspect how ProcessStartInfo preserves the inherited environment before launching the packaged Electron executable. Reproduce the PowerShell A/B/A comparison with orca status --json, then verify that successful CLI commands no longer emit the inherited Crashpad diagnostic while stdout remains valid JSON.

Written by the indexing model from the issue text.