fix(cli): spawn a version-manager CLI with its own node runtime (#16365)

* fix(cli): spawn a version-manager CLI with its own node runtime

resolveCliCommand falls back to scanning every version-manager install when
PATH misses, so it can hand back ~/.nvm/versions/node/v20.x/bin/codex while
PATH still leads with v22. Nothing paired the binary with the runtime it was
installed against, so its `#!/usr/bin/env node` shebang loaded a v20-built
native module under a v22 ABI and the agent died on first require (#10932).

Reproduced with a real addon rather than asserted: a CLI requiring a
cpu-features build for NODE_MODULE_VERSION 115, spawned with v24 leading
PATH, fails with ERR_DLOPEN_FAILED and exit 1. With the CLI's own bin
directory prepended it runs clean.

withCliRuntimeOnPath prepends the resolved command's directory when that
directory ships a sibling node, and is a no-op otherwise — so a Homebrew or
/usr/local CLI is untouched, and the WSL paths pass a bare `codex`/`claude`
that is not absolute and so never matches.

Host CLI resolution in the Claude login path is now lazy, keeping the WSL
branch from resolving a host binary it never spawns.

* fix(cli): split PATH on the delimiter we join with, pair app-server too

Readiness review findings, all four addressed.

withCliRuntimeOnPath chose its join delimiter from the platform option but
split with the host's. Passing platform:'win32' from a posix host turned
`C:\Windows;C:\Windows\System32` into `C;\Windows;C;\Windows\System32` —
every drive letter torn off at its colon. Latent, since no shipped caller
passes platform, but the sole win32 test was written against the corrupted
value and asserted one split segment, so it green-lit the shredding.

That test's other assertion was vacuous: it seeded only `Path`, so the
`PATH` key it asserted absent could never exist. Deleting the whole
case-dedupe block left the suite green. It now seeds both keys and asserts
the full joined string; removing the block fails it.

Nothing covered the wiring, and the argument choice is the easy thing to get
silently wrong. Note it only diverges on win32 — on posix
getSpawnArgsForWindows returns the CLI itself, so pairing the spawn command
is indistinguishable there. The new test drives the win32 branch with a .cmd
fixture; pairing spawnCmd or dropping the wrapper both fail it now.

codex-trust-grant-host and codex-session-index-heal spawn the same
`codex app-server` subcommand through runCodexAppServerSession and were left
unpaired. Pair centrally there via a new optional cliPath, since
invocation.command may be a cmd.exe wrapper.

Pairing tests live in their own file: adding them inline pushed
codex-fetcher.test.ts past the 800-line ratchet.

* fix(cli): read the Windows path key the child will actually use

Round-2 review finding. The read was narrower than the delete: the key was
picked from exactly two spellings (`Path`, else `PATH`), while the twin
dedupe removed every key whose lowercase form is `path`. A block spelling it
`path` or `pATh` therefore had its value deleted without ever being read,
handing the child a PATH containing only the CLI's own directory — a strictly
worse outcome than not pairing at all.

Win32 resolves env names case-insensitively and object order preserves block
order, so the entry the child reads is the first case-insensitive match. The
repo already encodes that rule in resolvePathEnvKey
(src/main/pty/windows-path-segment-merge.ts); src/shared cannot import from
src/main, so mirror it locally.

Verified by execution across six env shapes: lowercase, mixed-case, Path-only,
PATH-only, both twins, and a PATHEXT control that must not be touched. All
preserve the original PATH; before the fix the first two lost it entirely.
Reverting the selector fails the new test and nothing else.

src/shared/node-cli-command-resolution.ts

@@ -1,6 +1,6 @@
 import { accessSync, constants, existsSync, readdirSync, statSync } from 'node:fs'
 import { homedir } from 'node:os'
-import { delimiter, dirname, join } from 'node:path'
+import { delimiter, dirname, isAbsolute, join } from 'node:path'
 
 type ResolveCommandOptions = {
   pathEnv?: string | null
@@ -16,13 +16,16 @@ function getExecutableNames(platform: NodeJS.Platform, commandName: string): str
   return [commandName]
 }
 
-function splitPath(pathEnv: string | null | undefined): string[] {
+function splitPath(
+  pathEnv: string | null | undefined,
+  pathDelimiter: string = delimiter
+): string[] {
   if (!pathEnv) {
     return []
   }
 
   return pathEnv
-    .split(delimiter)
+    .split(pathDelimiter)
     .map((entry) => entry.trim())
     .filter(Boolean)
 }
@@ -209,6 +212,70 @@ export function resolveClaudeCommand(options: ResolveCommandOptions = {}): strin
   return resolveCliCommand('claude', options)
 }
 
+// Why: Win32 resolves env names case-insensitively and object order preserves
+// the block order, so the entry the child will actually read is the FIRST
+// case-insensitive match — not necessarily `Path` or `PATH`. Reading a narrower
+// set than the dedupe below deletes would destroy a third spelling unread.
+// Mirrors resolvePathEnvKey in src/main/pty/windows-path-segment-merge.ts, which
+// src/shared must not import.
+function firstWindowsPathEnvKey(env: NodeJS.ProcessEnv): string {
+  for (const key of Object.keys(env)) {
+    if (key.toLowerCase() === 'path' && env[key] !== undefined) {
+      return key
+    }
+  }
+  return 'Path'
+}
+
+/**
+ * Put a resolved CLI's own directory ahead of PATH when that directory ships a
+ * sibling `node`.
+ *
+ * Why: `resolveCliCommand` falls back to scanning every version-manager install
+ * when PATH misses, so it can hand back `~/.nvm/versions/node/v20.x/bin/codex`
+ * while PATH still leads with v22. The CLI's `#!/usr/bin/env node` shebang then
+ * loads a v20-built native module under a v22 ABI and the agent dies on first
+ * require (stablyai/orca#10932). Pair the binary with the runtime it was
+ * installed against instead.
+ *
+ * Only prepends when the sibling `node` really exists, so a CLI resolved from a
+ * directory that ships no node is left alone.
+ */
+export function withCliRuntimeOnPath<T extends NodeJS.ProcessEnv>(
+  commandPath: string,
+  env: T,
+  options: Pick<ResolveCommandOptions, 'platform'> = {}
+): T {
+  const platform = options.platform ?? process.platform
+  if (!isAbsolute(commandPath)) {
+    return env
+  }
+  const commandDirectory = dirname(commandPath)
+  if (!findFirstExecutable(platform, [commandDirectory], getExecutableNames(platform, 'node'))) {
+    return env
+  }
+  const pathKey = platform === 'win32' ? firstWindowsPathEnvKey(env) : 'PATH'
+  const pathDelimiter = platform === 'win32' ? ';' : delimiter
+  const segments = splitPath(env[pathKey], pathDelimiter)
+  if (segments[0] === commandDirectory) {
+    return env
+  }
+  const next = [commandDirectory, ...segments.filter((entry) => entry !== commandDirectory)].join(
+    pathDelimiter
+  )
+  const paired = { ...env, [pathKey]: next }
+  if (platform === 'win32') {
+    // Why: the spread is case-sensitive while Windows env lookup is not, so a
+    // differently-cased twin would keep shadowing the value we just wrote.
+    for (const name of Object.keys(paired)) {
+      if (name !== pathKey && name.toLowerCase() === pathKey.toLowerCase()) {
+        delete (paired as NodeJS.ProcessEnv)[name]
+      }
+    }
+  }
+  return paired as T
+}
+
 // Why: Node-script CLIs need their version-manager sibling `node` on PATH.
 export function getVersionManagerBinPaths(options: ResolveCommandOptions = {}): string[] {
   const platform = options.platform ?? process.platform