Codex CLI in gstack skills 400s on ChatGPT-account auth — model entitlement issue, needs `-m gpt-5.2` injection

## Problem

codex CLI v0.121.0 defaults to `gpt-5.2-codex`. ChatGPT-account (Plus) auth no longer serves any `*-codex` model variant since ~March 2026 (OpenAI server-side entitlement regression, not a billing cap — caps are 429/402, this is 400 `invalid_request_error`). Rejected slugs: `gpt-5.2-codex`, `gpt-5-codex`, `gpt-5.1-codex`, all `*-codex-mini`, `codex-mini-latest`, AND plain `gpt-5`. Working slug on ChatGPT auth: `gpt-5.2` (general model, same generation, no `-codex` tuning).

Refs: openai/codex#19654, openai/codex#14735, openai/codex#14412.

## Impact on gstack

Every gstack skill that shells codex constructs the command **without `-m`**, so every codex invocation 400s on ChatGPT-account users. Affected skills (non-exhaustive):

- `/plan-eng-review` — Outside Voice step (`codex exec`)
- `/codex` — review / challenge / consult modes (`codex review`, `codex exec`)
- `/ship` — adversarial review step
- `/autoplan` — pipeline of the above
- `/plan-ceo-review` — Outside Voice step
- `/plan-design-review` — Outside Voice step

API-key users (`OPENAI_API_KEY` set, no ChatGPT auth) are unaffected. Blocked for every ChatGPT-account codex invocation until users manually add `-m` per command or globally configure their `~/.codex/config.toml`.

## Failure shape

```
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-5.2-codex' model is not supported when using Codex with a ChatGPT account."}}
```

(swap the model slug per CLI version default)

## User-side workaround (per-command)

Inject `-m gpt-5.2` into every codex invocation. Cost-isolation preserved: `-m` only changes the slug; auth still resolves from `~/.codex/auth.json` (ChatGPT/Plus flat-rate). Does NOT switch to API-key auth.

```bash
# codex exec
codex exec "" -C "$REPO_ROOT" -s read-only -m gpt-5.2 -c 'model_reasoning_effort="high"' < /dev/null

# codex review (NOTE: no -m/--model flag on this subcommand in v0.121.0 — model goes via -c)
codex review --base origin/main -c model="gpt-5.2" -c model_reasoning_effort="high"
```

## User-side workaround (durable / config)

```toml
# ~/.codex/config.toml
model = "gpt-5.2"
model_reasoning_effort = "high"
```

This fixes ALL sessions globally. Per-user opt-in if global config doesn't match their setup.

## Probe trap

Do NOT verify model selection with a trivial "reply with exactly: OK" probe — codex silently falls back to a working default and echoes the string regardless of `-m`, so the probe false-positives. Verify with a real task and grep stderr for `not supported when using Codex` to distinguish entitlement-rejection from success.

## Proposed direction

Inject `-m gpt-5.2` into the codex invocations in shipped skill files (the mechanical fix unblocks ChatGPT-account users immediately). Longer-term, detecting auth type at skill-time and only injecting when ChatGPT-auth is detected would avoid locking the model slug for API-key users who can still use `*-codex` — but that's a maintainer-shape call.

## Repro

```bash
codex exec "what's 2+2" -s read-only < /dev/null
# 400 invalid_request_error on ChatGPT-account
codex exec "what's 2+2" -s read-only -m gpt-5.2 < /dev/null
# works
```

## References

- openai/codex#19654, #14735, #14412 (model-entitlement reports)
- Community thread: "gpt-5-2-codex model is not supported"
- Surfaced in a downstream gstack-using workflow when `/plan-eng-review` Outside Voice 400'd against ChatGPT-Plus auth (2026-05-20)