Stabilize Codex CLI discovery

[AriaShishegaran]

Summary

• add a shared Codex command resolver used by both chat execution and codex debug models
• cover supported macOS install families: standalone installer default (~/.local/bin/codex), legacy local install, npm user-global prefix, nvm versions, Homebrew, common Node/tool-manager shims, and app-inherited PATH entries
• preserve explicit command override behavior for arbitrary/manual install locations

Closes #70

Why

Easel launches Codex from a macOS GUI app process, which may not inherit the user's interactive shell PATH. That made supported installs fail when codex worked in Terminal but lived outside the previous hardcoded paths.

Upstream references checked while preparing this PR:

• OpenAI Codex CLI docs list the standalone installer and show codex as the run command: https://developers.openai.com/codex/cli
• The current standalone installer defaults CODEX_INSTALL_DIR to $HOME/.local/bin, producing $HOME/.local/bin/codex: https://chatgpt.com/codex/install.sh
• The upstream OpenAI Codex README documents npm, Homebrew, and downloadable release binaries renamed to codex: https://github.com/openai/codex#installing-and-running-codex-cli

Validation

• swift test --package-path Packages/EaselClaudeCodeUI
  • 122 tests passed, 0 failures
• swift test --package-path Packages/EaselClaudeCodeUI --filter CodexCommandResolverTests
  • 9 resolver tests passed, 0 failures
• local real-world check: ~/.npm-global/bin/codex debug models returned model JSON
• prior debug launch through Easel showed CodexSDK JSON events streaming from a real Easel project with no Codex-not-found error

Notes

Manual installs in arbitrary directories cannot be discovered deterministically by a Finder-launched app. Those remain supported through the explicit Codex command override in settings.

[jamesrochabrun]

@AriaShishegaran I pushed a small follow-up to keep the resolver abstraction while removing the precedence regression.

The issue was that fixed Homebrew paths were checked before discovered nvm/PATH installs. On machines that have both, that can run a stale global Homebrew Codex instead of the user-selected nvm/PATH Codex, and it also made the new tests depend on what happened to be installed on the developer/CI machine.

The updated ordering keeps Homebrew as a final fallback: explicit/local candidates, PATH/nvm/tool-manager candidates, and the SDK detector all get a chance first. I also made the Homebrew directories injectable in tests so the resolver tests do not depend on the host machine, and added regression coverage for nvm, PATH, and SDK detector candidates winning over Homebrew.

Verified with:

• swift test --package-path Packages/EaselClaudeCodeUI --filter CodexCommandResolverTests (13 tests)
• swift test --package-path Packages/EaselClaudeCodeUI (126 tests)