Connect writes ?apikey= URLs for Codex and the generic fallback, which mcp_reject_query_apikey then refuses #1709

Problem

#1696 adds mcp_reject_query_apikey, which answers any MCP request carrying ?apikey= with a 401. The Connect wizard still writes two client entries with the credential in the URL:

• Codex: internal/connect/clients.go buildServerEntry, case "codex" writes url: <base>?apikey=<mcp_cli_…> via credentialQuery (internal/connect/connect.go:357-366), with a comment saying Codex cannot take a literal header. docs/features/connect-clients.md says Codex supports env_http_headers and literal http_headers, which contradicts that comment.
• The generic fallback entry (default: branch) uses the same query carrier.

Connect mints a credential even with require_mcp_auth off (connect.go:333-350), and nothing in the Connect flow or in doctor / attention knows about the new option. So a user who connects Codex with the wizard and then turns the option on gets a silent 401 from their own proxy, and Connect keeps writing the broken shape.

Expected

One of:

1. Connect writes a header carrier for Codex (env_http_headers plus an env var, or http_headers if literal values are supported; reconcile the doc and the code comment first) and for the generic fallback where possible.
2. While mcp_reject_query_apikey is on, Connect refuses or warns for carriers that can only use the query form, and doctor reports clients configured with ?apikey=.

Also: refusals under the option are not logged, so an operator cannot see which client still uses the query form; a single warn-level log line (client name if known, no token) would help migration.

Found during the review of #1696 (maintainer read plus opencode Sol 6.1).