Make MCP server contributions thread-scoped

[jif-oai]

Why

selectedCapabilityRoots belongs to one thread, but MCP contributors previously received only the global Codex config. That left no clean way for a selected executor capability to contribute MCP servers to its own thread.

What this PR does

• Gives MCP contributors a small context containing the config and, for a running thread, its frozen host-seeded inputs.
• Uses the same thread inputs during startup, status queries, refreshes, and skill dependency checks.
• Keeps threadless MCP operations and the existing hosted Apps behavior unchanged.
• Adds coverage showing that two threads resolve independent registrations and that later lifecycle mutations do not change the frozen MCP inputs.

This PR does not discover plugin manifests, add MCP servers, or launch anything new. It only establishes the thread-scoped registration boundary.

Follow-ups

• Resolve selected executor plugin roots through their owning environment filesystem.
• Convert their stdio MCP declarations into environment-bound registrations and add an executor MCP end-to-end test.

Verification

• just fmt
• cargo check --tests -p codex-protocol -p codex-extension-api -p codex-mcp-extension -p codex-core -p codex-app-server

Tests and Clippy were not run.

[jif-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f8256a5751

ℹ️ 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".