codex: add fullLane config to escape Responses Lite for sol/terra (parallel tool calls) - #77

Problem

Ref #36. The gpt-5.6 family (luna / sol / terra) is pinned to the Responses Lite lane, and the Lite branch of translate_request forces parallel_tool_calls: false. Through the proxy these models therefore emit at most one tool_use per assistant turn, and Claude Code's parallel tool batching degrades into serialized round-trips — the dominant latency cost on tool-heavy agentic work (multi-file reads, subagent fan-outs).

Answer to the open question in #36

It is a backend constraint, but only inside the Lite lane. Verified with CCP_TRAFFIC_LOG=1 wire captures:

• Sending parallel_tool_calls: true on the Lite lane is rejected with:

  400 unsupported_value — "X-OpenAI-Internal-Codex-Responses-Lite requires `parallel_tool_calls` to be false."
  

  So flipping the default inside Lite is not possible; the existing false is correct there (this PR adds a comment saying why).

• gpt-5.6-sol and gpt-5.6-terra also exist on the full Responses lane — the same lane full_lane_web_search_model already upgrades luna to for hosted web_search. On the full lane, parallel tool calls work: a prompt asking for three independent file reads produced tool_use ×ばつ3 in a single response, 3/3 repetitions (vs 1 tool call, 3/3, on Lite with the identical prompt).

Change

• codex.fullLane / CCP_CODEX_FULL_LANE (default false): routes gpt-5.6-sol and gpt-5.6-terra through the full Responses lane. Default behavior is unchanged.
• gpt-5.6-luna ignores the override — the full lane resolves it to a -free variant and 404s (matches the existing comment on full_lane_web_search_model).
• README: config table row + a "Responses lanes and parallel tool calls" note in the Codex provider section.

Checks on the full lane (gpt-5.6-sol, WebSocket transport)

• Parallel tool calls: ×ばつ tool_use in one response, 3/3 reps
• Prompt caching: 52k-token context, turn 2+ cache_read_input_tokens ≈ 52k (same as Lite)
• Warm TTFB 1.2–1.6 s, comparable to Lite
• Billing signals looked identical in captures (same plan_type, credit balance unchanged across full-lane requests), but I can't rule out lane-dependent quota accounting — one reason this is opt-in rather than a default flip

Tests

• uses_responses_lite split into a pure uses_responses_lite_with_full_lane (mirrors the resolve_effort_override pattern) with unit tests for default/override/luna-exempt cases
• Config test for codex.fullLane file value + CCP_CODEX_FULL_LANE env precedence
• cargo fmt clean; cargo test --all passes (499 lib tests + integration). cargo clippy -D warnings on my toolchain flags pre-existing lints in cursor/monitor files untouched by this PR (newer clippy than CI's, I assume)

🤖 Generated with Claude Code

https://claude.ai/code/session_01TWQpX1wPzyQNa544xWuoiY