feat: accept max and ultra reasoning efforts

[t-sato]

Summary

--effort max and --effort ultra are rejected by the companion even though Codex supports both:

$ node plugins/codex/scripts/codex-companion.mjs task --effort max "reply OK"
Unsupported reasoning effort "max". Use one of: none, minimal, low, medium, high, xhigh.

VALID_REASONING_EFFORTS in plugins/codex/scripts/codex-companion.mjs has been a hardcoded list since the initial commit and has drifted from Codex. This PR adds max and ultra to it, and updates the usage string, error message, argument-hint, runtime skill, README, and tests to match.

Why these values are valid

1. The models advertise them. From codex debug models (codex-cli 0.146.1):

model	advertised reasoning levels
gpt-5.6-sol	low, medium, high, xhigh, max, ultra
gpt-5.6-terra	low, medium, high, xhigh, max, ultra
gpt-5.6-luna	low, medium, high, xhigh, max
gpt-5.5	low, medium, high, xhigh
gpt-5.4, gpt-5.4-mini	low, medium, high, xhigh
gpt-5.3-codex-spark	low, medium, high, xhigh

Codex's own instructions agree: "GPT-5.6 supports none, low, medium, high, xhigh, and max. If omitted, GPT-5.6 defaults to medium."

2. The app-server protocol does not model effort as a closed enum. From codex app-server generate-ts:

// v2/TurnStartParams.ts
effort?: ReasoningEffort | null

// ReasoningEffort.ts
export type ReasoningEffort = string;

Effort is an open string, and Codex validates it against the reasoning levels the selected model advertises. A hardcoded allowlist in the plugin is therefore guaranteed to fall behind — and it already has, in both directions: it still accepts none and minimal, which no model in the current catalog advertises, while rejecting max and ultra, which the current models do.

3. Verified end to end against a real Codex run through the app-server path this plugin uses:

$ node plugins/codex/scripts/codex-companion.mjs task \
    --model gpt-5.6-luna --effort max "Reply with exactly: OK"
[codex] Starting Codex task thread.
[codex] Thread ready (019fe094-6c30-7461-b323-4b2a29c29bd7).
[codex] Turn started (019fe094-74f9-7301-84a6-853dae641467).
[codex] Assistant message captured: OK
[codex] Turn completed.
OK

Note on #99

#99 (closing #77) changed the README example from model_reasoning_effort = "xhigh" to "high" on the grounds that xhigh was unsupported. xhigh is in fact advertised by every model in the catalog above, including the gpt-5.4 generation current at the time. That change is unrelated to this PR's diff, but it's the same root cause: the effort list has never tracked upstream. Happy to send a follow-up restoring that example if you'd like.

Design choice

Per-model validation stays with Codex, which is where the model catalog lives. The companion's list only rejects values Codex has no variant for at all, so --effort ultra on a model that does not advertise ultra is Codex's error to raise, not the plugin's.

If you'd prefer the stricter version, I can narrow this to max only and drop ultra. If you'd prefer the looser one, dropping the allowlist entirely and forwarding any non-empty string is the option that matches the protocol's own design most closely — say the word and I'll rework it.

Tests

Added to tests/runtime.test.mjs:

• max and ultra are forwarded to app-server turn/start (table-driven over both values)
• an unknown effort is still rejected

Updated the --effort assertions in tests/commands.test.mjs.

npm test from a clean state: 90 pass, 4 fail. The 4 failures (resolveStateDir uses a temp-backed per-workspace directory, status shows phases, hints, and the latest finished job, status preserves adversarial review kind labels, result returns the stored output for the latest finished job by default) reproduce identically on main with this branch stashed, so they are pre-existing on my machine and not introduced here. Two contributing factors I found while bisecting, in case they're useful:

• The setup/status/result tests run with cwd: ROOT and leave plugin state (broker.json, jobs/) in the repository's own state directory. A second npm test run in the same checkout then sees a registered shared runtime, and five setup tests flip to ready: true. Deleting the state directory restores them.
• resolveStateDir uses a temp-backed per-workspace directory fails whenever CLAUDE_PLUGIN_DATA is set in the environment, which it is when the suite is run from inside Claude Code with this plugin installed. It passes under env -u CLAUDE_PLUGIN_DATA.

Both are out of scope here; I can open separate issues.

[j7an]

@dkundel-openai duplicate PRs has been getting closed. When do we expect current PR to be reviewed, merged, and release created?