Expand client support only through verified model-traffic boundaries

## Goal

Increase the number of supported coding agents and clients without treating a launcher, generic proxy setting, or nominally OpenAI-compatible endpoint as complete support.

## Requirements

- Track each client and each surface separately: CLI, desktop app, editor extension, remote host, cloud task, background model, and completion/indexing traffic.
- Require a documented or observed model-traffic boundary before advertising support.
- Verify prompt masking, tool-result masking, opaque-handle use, local restoration, streams, errors, files, and images as applicable.
- Preserve the user's existing configuration and restore it after normal exit, crash, cancellation, and failed startup.
- Distinguish native OpenAI, Anthropic, Gemini, Cloud Code, and provider-specific protocols.
- Mark authenticated testing gaps explicitly instead of claiming support from mocked traffic alone.
- Generate the public compatibility table from test evidence.
- Add focused implementation issues per client rather than turning this issue into a promise to support every product.

## Initial priority

Keep Codex, Claude, OpenCode, and Pi reliable first, then promote additional clients only when their relevant paths pass release E2E.

No implementation files or tests are named. Start by identifying the client-specific implementation and release E2E entry points for Codex, Claude, OpenCode, and Pi; done means relevant paths have verified traffic-boundary evidence, configuration-restoration coverage, and compatibility-table evidence.

Written by the indexing model from the issue text.