feat: allow selecting a Codex profile for companion-launched jobs

[kiddingbaby]

Problem

codex-plugin-cc spawns the underlying codex CLI (via scripts/codex-companion.mjs → scripts/lib/codex.mjs) without propagating any profile selection. All companion-launched jobs (setup / review / adversarial-review / task / ...) run against whatever sits at the top of ~/.codex/config.toml — either the global default fields or the top-level profile = "..." shortcut.

A user who maintains several profiles in config.toml (e.g. one per provider / endpoint, or a dedicated "review" profile with a different reasoning effort) cannot point a single Claude Code session at a non-default profile without editing their global config. The plugin UI has no way to say "for this session, use [profiles.tmp]".

Current behavior

• node codex-companion.mjs --help exposes --model and --effort, but no --profile.
• Source grep confirms: scripts/ has zero references to profile / --profile / CODEX_PROFILE. The child codex invocation never receives -p <name> or -c profile=<name>.
• Codex CLI itself does support -p <name>, top-level profile = "..." in config.toml, and -c profile=<name> overrides (https://developers.openai.com/codex/config-advanced).

Workaround (limited)

Set profile = "<name>" at the top of ~/.codex/config.toml. That works globally but:

1. It is a global switch, not per-repo or per-session.
2. It conflicts with users who want different profiles for /codex:review, /codex:task, or direct codex TUI invocations.
3. Project-level .codex/config.toml helps, but requires scattering TOML files across target repos.

Proposed

Let codex-companion.mjs forward a profile selector to the spawned codex process. Two touch points, both additive:

1. CLI flag: --profile <name> on review / adversarial-review / task / setup. When present, the companion passes -p <name> (or -c profile=<name>) to codex.
2. Env var: CODEX_COMPANION_PROFILE. When set and no explicit flag, use it as the default for companion-launched jobs.

Neither changes behavior for existing users — both are opt-in.

Why this matters

For skill chains that hand off to codex-plugin-cc (e.g. an agentstack-style agentstack:review → /codex:review handoff), being able to say "this repo uses profile X" at the plugin layer removes a whole class of config-edit churn when users juggle multiple model providers or reasoning-effort presets.

Related

• upstream: openai/codex#17533 — review command doesn't honor custom profiles (different layer but symptomatic of the same gap)
• this repo: Expose sandbox mode as env var / config knob for review and adversarial-review #167 (sandbox mode as env var), feat: support user-level defaults for companion config (e.g. stopReviewGate) #213 (user-level defaults for companion config) — adjacent UX asks

Alternative considered

A generic pass-through: codex-companion.mjs review -- -p tmp ... that forwards everything after -- to codex. Simpler, more flexible, less discoverable. Combinable with the flag above.

[dhruvac29]

Opened a fix here: #256

I traced this against the current codebase and the gap is still real, but the runtime path is now app-server-based rather than a direct codex -p ... spawn. This PR adds --profile <name>, CODEX_COMPANION_PROFILE, and tests covering profile forwarding and precedence.