PR: Robustness for the claude/codex backends on Windows

What

Independent robustness fixes surfaced running SkillOpt end-to-end on the bundled
claude backend (local Claude CLI, claude_chat) on Windows. Six files, ~100
lines added / 4 changed; no behavior change on the OpenAI/GPT happy path.

1. skillopt/engine/trainer.py — create the test-eval dirs before writing.
test_eval_baseline/, test_eval/, and test_eval_final/ are each written to
(summary.json) before being created. When a rollout yields zero predictions the
dir never gets made by the rollout side, so the write raises FileNotFoundError
on Windows. Adds os.makedirs(..., exist_ok=True) at all three sites (the third,
the test_eval_final else-branch, mirrors the if-branch that already had it).

2. skillopt/model/claude_backend.py — keep large content off argv, pin UTF-8.

• (a) Prompt via stdin, not argv. The prompt rode on the command line
  (cmd + [prompt_for_cli]). Windows caps a command line at ~32 KB, so a large
  optimizer prompt — the success-analyst minibatch carrying several report
  trajectories, i.e. as soon as use_meta_skill / use_slow_update is on or
  minibatch_size is raised — overflows with
  [WinError 206] The filename or extension is too long and kills the run after
  retries. claude -p reads the prompt from stdin when no positional arg is given.
• (b) System prompt via --append-system-prompt-file, not argv. The ~32 KB
  cap applies to the sum of all argv, and the system prompt here is the skill
  being optimized — which SkillOpt grows over training. Once it passes ~30 KB it
  re-hits WinError 206 even with the prompt on stdin. Writing it to a temp file
  removes the last unbounded term from argv.
• (c) Pin subprocess encoding to utf-8 (errors="replace"). With
  text=True and no encoding=, stdin is encoded with the system codepage; on a
  zh-CN box (cp936/GBK) a prompt containing an emoji or some Latin-1 chars raises
  UnicodeEncodeError before the CLI even starts, failing every retry.

3. skillopt/model/codex_backend.py — same UTF-8 encoding pin on its
subprocess.run(input=...) call (identical unpinned-encoding pattern).

4. skillopt/utils/json_utils.py — tolerant, unambiguous-only JSON repair.
Strict json.loads rejects valid-looking JSON that non-OpenAI backends emit
(unescaped ASCII quotes inside CJK string values, trailing commas); extract_json
then returns None and the reflect step silently treats it as "0 edits" — the
skill never improves, with no error logged. Adds a json_repair fallback, but
only on a single unambiguous object: a balanced-brace extractor plus a
refuse-on-multiple-objects guard. This is deliberate — feeding the old greedy
{.*} span (or the raw text) to json_repair makes it silently return one of
several objects (empirically the wrong/discarded one from a chain-of-thought
"scratch + final" response), which is worse than None (None is detectable and
retryable; a wrong-but-valid edit is applied blind). json_repair is added to
requirements.txt and the claude/qwen extras (it otherwise no-ops on a fresh
install — dropping the very edits it exists to save — now with a one-time warning).

Why

All surfaced running the loop on Windows + claude_chat. Fix 2a/2b hard-kills any
non-trivial run ([WinError 206]) the moment prompts/skills grow. Fix 4 is a
silent failure: the analyst returns good edits, the run logs → 0 edits /
reflect_s=0.0, and the skill is frozen across every step. After the fixes a small
run optimizes normally (seed skill hard 0.0 → 1.0, generalizing to held-out
items) and larger runs (use_meta_skill + use_slow_update, multi-epoch) no
longer crash.

Testing

• Fix 2a: a >32 KB prompt that raised [WinError 206] on argv completes via
  stdin; confirmed claude -p reads the piped prompt and returns JSON.
• Fix 2b: --append-system-prompt-file confirmed supported by the installed
  CLI; the skill-as-system-prompt path no longer occupies argv.
• Fix 2c / 3: under PYTHONUTF8=0 (cp936), a prompt with an emoji / Latin-1
  char raised UnicodeEncodeError; with the pin it succeeds.
• Fix 4: 9-case unit check — genuine single malformed objects (trailing comma,
  unescaped CJK quotes, nested, fenced) still repair to the right dict; a
  {KEEP} (scratch: {DISCARD}) / first {KEEP} final {REWRITE} multi-object
  response returns None (never the discarded object), where the prior fallback
  returned the wrong one.
• Patch hygiene: applies cleanly to pristine fc1f827 (git apply --check
  and git am both OK); patched tree byte-compiles; OpenAI path untouched
  (json_repair only reached after strict parse fails; makedirs idempotent; stdin
  and encoding are backend-agnostic).

Notes

If you'd prefer json_repair not be a dependency, the fallback degrades gracefully
(try/except ModuleNotFoundError → returns None with a one-time warning), so it
can stay extras-only.