fix(deep-scan): avoid unspawnable Windows Codex paths

[kmbroai]

What changed

• Keep an inherited CODEX_CLI_PATH for nested Deep Scan workers on Windows only when it names a directly spawnable .exe or .com launcher outside WindowsApps.
• Normalize case-variant CODEX_CLI_PATH keys before forwarding the MCP/worker environment.
• Fall back to the existing resolveCodexCommand() platform-package resolver for extensionless npm shims, batch launchers, blank values, and protected WindowsApps executables.
• Add focused regression coverage for a working per-user codex.exe, extensionless npm codex, codex.cmd, and a WindowsApps codex.exe.

Why

The bundled Deep Scan executor passes CODEX_CLI_PATH to @openai/codex-sdk as codexPathOverride, and that SDK launches it directly with child_process.spawn. The public SDK already forwards the exact uppercase variable through the MCP manifest, but it previously trusted every nonblank inherited value. On Windows that can select either the extensionless npm shim or the desktop app's protected C:\Program Files\WindowsApps\...\codex.exe; both fail before discovery with spawn EPERM, even though the package's native platform executable is available.

This keeps explicit executable overrides working while using the existing bundled resolver for launchers Node cannot directly spawn. It does not change sandbox settings.

Links: CLI-18410, openai/codex#35872

Validation

• /home/dev-user/.bun/bin/bun test tests-ts/runtime.test.ts --test-name-pattern 'uses only directly spawnable Windows Codex overrides for nested workers'
• pnpm run types, pnpm run format, and pnpm run build
• TMPDIR=/home/dev-user/.codex-security-cli18410-temp /home/dev-user/.bun/bin/bun test --timeout 30000 ./tests-ts (1,039 pass, 10 expected skips, 0 fail)
• pnpm pack --pack-destination ../../dist and pnpm run test:package (installed-package nested worker smoke passed)
• codex review --base origin/main (no actionable findings)