Windows / Git Bash: /codex challenge mangles quoted prompt argv; stdin-fed prompt works

## Note

Related to #1674, but this is a different observed failure mode.

#1674 covers Windows argv length / CreateProcess limit failures when generated prompts are large. This issue reports a separate Windows + Git Bash failure mode with the same risky invocation pattern: quoted prompt argv mangling when the prompt contains embedded double-quotes.

The likely fix is the same - pass generated prompts through stdin via `codex exec -` - but this issue documents that the argv-prompt pattern can fail even before / apart from the length-limit case.

## Summary

On Windows 10 + Git Bash, `/codex challenge` failed because the generated prompt was passed as a positional argv to `codex exec`.

The prompt contained embedded double-quotes, for example snippets like:

```bash
model_reasoning_effort="high"
git diff "$DIFF_BASE"
```

In this environment, the positional prompt appeared to be re-split / mangled before reaching `codex.exe`. Claude Code retried by feeding the prompt through stdin instead, and that succeeded.

Verbatim from the session:

> The codex run failed - the `--enable web_search_cached` flag is deprecated AND the prompt arg got mangled by shell quoting on Windows. Let me retry with stdin-fed prompt and without the deprecated flag.

## Environment

- OS: Windows 10
- Shell: Git Bash / MSYS
- Command: `/codex challenge`
- gstack: 1.44.0.0
- codex CLI: codex-cli 0.128.0
- Claude Code: latest as of 2026-05-24

## Repro

Inside Claude Code on Windows + Git Bash:

```bash
/codex challenge
```

The failing path used a `codex exec ""` style invocation, where the generated prompt was passed as a positional argument and contained literal `"` characters.

Observed result:

- `codex exec` failed before returning useful model output
- the positional `[PROMPT]` appeared truncated / re-split around embedded quotes
- retrying the same prompt via stdin succeeded

## Why this matters

Passing generated multi-line prompts as argv is fragile on Windows + Git Bash. MSYS2 documents automatic process argument conversion when calling native Windows executables from MSYS/Cygwin-like environments, and explicitly notes that this conversion is "not perfect and in corner cases converts arguments that look like Unix paths while they are not" - with `MSYS2_ARG_CONV_EXCL` provided as an escape hatch. See [MSYS2 docs - Filesystem Paths / Process Arguments](https://www.msys2.org/docs/filesystem-paths/).

Long generated prompts with embedded quotes are exactly the kind of payload that hits these corner cases. Using stdin avoids the boundary for prompt content entirely.

## Suggested fix

For `codex exec` call sites that currently pass generated prompts as positional argv:

```diff
- codex exec "$PROMPT" \
+ codex exec - \
-C "$_REPO_ROOT" \
-s read-only \
-c 'model_reasoning_effort="high"' \
- --json
+ --json <<< "$PROMPT"
```

Primary fix:

- pass generated prompts via stdin using `codex exec -`

Secondary cleanup:

- drop `--enable web_search_cached` where it is still emitted, since that appears to be deprecated and already discussed in #971

If a more portable shape is preferred over the bash here-string, `printf '%s' "$PROMPT" | codex exec - ...` works the same way.

## Related

- #1674 - Windows argv length / CreateProcess limit; same risky `codex exec ""` pattern, same likely stdin-based fix, different observed failure mode.
- #971 - `codex exec` stdin/deadlock issue and `