`write-proxy-config` step injects a `model_provider` key into the user's `CODEX_HOME` config leading to duplicate key error

Summary

When openai-api-key is provided, the action's write-proxy-config step injects a model_provider key into the user's CODEX_HOME config. If the user's config.toml already defines model_provider and [model_providers.*], the Codex CLI fails with a TOML "duplicate key" error at startup.

Context

We use codex-action@v1 with a custom CODEX_HOME that contains a config.toml defining our Azure OpenAI provider:

model = "gpt-5.3-codex"
model_provider = "azure"
model_reasoning_effort = "high"

[model_providers.azure]
name = "Azure"
base_url = "<deployment-endpoint>"
env_key = "AZURE_OPENAI_API_KEY"
query_params = { api-version = "2025-04-01-preview" }
wire_api = "responses"

The workflow also passes openai-api-key and responses-api-endpoint:

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.AZURE_OPENAI_API_KEY }}
    responses-api-endpoint: https://...
    prompt-file: .github/codex/prompts/custom-prompt.md
  env:
     ...

The action starts the codex-responses-api-proxy, then the write-proxy-config step writes its own model_provider config into CODEX_HOME. This conflicts with the existing model_provider = "azure" in our config.toml, producing:

Error loading config.toml:
config.toml:6:1: duplicate key
  |
6 | model_provider = "azure"
  | ^^^^^^^^^^^^^^

Current workaround: Comment out the model_provider and [model_providers.*] block in config.toml and let the action handle provider config at runtime. This works but means the provider settings are split across two places (workflow YAML and config.toml) and local codex exec runs require uncommenting the block.

What should be fixed

• write-proxy-config should not conflict with an existing model_provider in the user's config.toml (e.g. by merging rather than duplicating, or by writing to a separate overlay file)
• Users can define their Azure provider in config.toml and still pass openai-api-key to the action without a TOML parse error
• The same config.toml works for both CI (via codex-action) and local runs (via codex exec) without manual commenting/uncommenting

Start by locating the write-proxy-config step and trace how it writes into CODEX_HOME/config.toml when openai-api-key and responses-api-endpoint are provided. Compare that behavior with the documented model_provider and [model_providers.*] entries, then verify that an existing Azure provider can be used by both codex-action@v1 and local codex exec without a TOML duplicate-key error.