## What happened?

When using `use_chat_completions_api: true` to bridge the Responses API to Chat Completions for providers that don't support `/v1/responses` (e.g., DeepSeek, Z.AI/GLM, MiniMax), two bugs in `transform_responses_api_tools_to_chat_completion_tools` cause failures:

### Bug 1: Unsupported tool types forwarded as-is

When Codex or other clients send tools with `type: "custom"` (a valid Responses API tool type per the OpenAI SDK's `CustomToolParam`), the `else` branch in `transform_responses_api_tools_to_chat_completion_tools` passes them through unchanged:

```python # Current code (line ~1411) else: chat_completion_tools.append( cast(Union[ChatCompletionToolParam, OpenAIMcpServerTool], tool) ) ```

Providers like DeepSeek reject this: `tools[0].type: unknown variant 'custom', expected 'function'`.

### Bug 2: Function tool names lost during transformation

When clients send tools in Chat Completion format nested under the Responses API (which Codex does), the transformation only reads `name` from the top level of the tool dict:

```python # Current code (line ~1394) "name": typed_tool.get("name") or "", # Returns "" when name is nested under "functi…