Support Codex namespace tools in the Responses API

## Problem

Codex CLI 0.150.1 sends a client-side `namespace` tool through the Responses API. The gateway rejects the request before inference:

```text
tools[5].type: unknown variant `namespace`, expected one of
`function`, `web_search`, `web_context_search`, `file_search`,
`code_interpreter`, `computer`, `mcp`
```

Reproduced against `https://inference.phala.com/v1/responses` with `deepseek/deepseek-v4-flash`. Setting the following makes the same request succeed:

```toml
[features]
multi_agent = false
```

Codex currently requires `wire_api = "responses"`; its Chat Completions wire mode has been removed.

## Proposed behavior

Support Codex namespace tools by flattening namespace members into uniquely named `function` tools before upstream forwarding, then map returned function calls back to the original namespace/name pair.

## Acceptance criteria

- Codex CLI works with multi-agent enabled through `/v1/responses`.
- Namespace tool calls round-trip correctly.
- Existing standard Responses tool types keep their current behavior.
- Add an integration test using a captured Codex request.
- Document or publish a Codex `model_catalog_json` for Redpill models so custom model slugs load without the fallback metadata warning.

Start by tracing Responses API tool validation and forwarding, then inspect how returned function calls are mapped back to requests. Use a captured Codex request for the integration test and verify namespace calls round-trip while standard tool types retain their behavior. Also review the model_catalog_json requirement for Redpill model slugs.

Written by the indexing model from the issue text.