[codex] Preserve disabled MCP servers across runtime overlays

[e-provencher]

Why

Recent MCP runtime overlay changes replace same-name configured server entries with compatibility or extension-provided configs. Those replacement configs default to enabled, so an MCP server explicitly configured with enabled = false could be initialized anyway.

The connection manager still filters disabled servers correctly, but the configured disabled state was lost before initialization reached that filter.

What changed

• Remember MCP servers that are disabled in the configured view before applying runtime fallbacks and extension overlays.
• Restore enabled = false for those servers after overlays, while leaving all other overlay fields and Remove precedence unchanged.
• Add focused extension-backed regression coverage for a disabled codex_apps server.

Testing

• just fmt
• just test -p codex-mcp-extension
• just fix -p codex-core
• just fix -p codex-mcp-extension

The full workspace just test suite was not run.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[e-provencher]

I have read the CLA Document and I hereby sign the CLA

[jif-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d1db1d33d1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Cover disabled Apps tools through a Codex turn

This only asserts effective_servers, so it can pass even if a Codex turn still sends codex_apps tools in /responses. Because this overlay changes agent MCP tool exposure, add a core/suite test_codex turn asserting disabled Apps tools are absent from the model request, per guidance.

Useful? React with 👍 / 👎.