Add executor-owned plugin resolution

[jif-oai]

Why

CCA can select a capability root that lives in an executor environment, but
Codex only had a host-filesystem plugin loader. Before selected executor
plugins can contribute MCP servers, we need a small package boundary that can
answer:

Does this selected root contain a plugin, and if so, what does its manifest
declare?

The answer must come from the selected environment's filesystem. A failed
executor lookup must never fall back to the orchestrator filesystem.

What this changes

This PR introduces:

PluginProvider::resolve(root)
    -> Result<Option<ResolvedPlugin>, Error>

ExecutorPluginProvider resolves one SelectedCapabilityRoot through its
exact environment_id. It checks the recognized manifest locations, reads the
manifest through that environment's ExecutorFileSystem, and returns an inert
ResolvedPlugin containing:

• the opaque selected-root ID;
• the environment-bound plugin root;
• the authority-bound manifest resource;
• parsed metadata and authority-bound component locators.

Descriptor construction rejects manifest or component paths outside the
selected package root, so consumers cannot accidentally lose the package
boundary when they receive a resolved plugin.

If the root has no plugin manifest, resolution returns None, allowing the
caller to treat it as a standalone capability such as a skill.

selected root: repo -> env-1:/workspace/repo
                         |
                         | env-1 filesystem only
                         v
             .codex-plugin/plugin.json
                         |
                         v
        ResolvedPlugin { authority, root, manifest }

The existing host loader and the new executor provider now share the same
manifest parser. Existing codex-core-plugins::manifest type paths remain
available through re-exports, so host behavior and callers are unchanged.

Scope

This is intentionally a non-user-visible package-resolution PR. It does not:

• parse or register plugin MCP server configurations;
• activate skills, connectors, hooks, or MCP servers;
• change app-server wiring;
• introduce host fallback, caching, or lifecycle behavior.

#27670 has merged, and this PR is now based directly on main. Together with
the resolved MCP catalog from #27634, it establishes the inputs needed for the
executor stdio MCP vertical without changing the existing MCP runtime.

Follow-up

The next PR will consume ResolvedPlugin, read its declared/default MCP config
through the same executor filesystem, bind supported stdio servers to that
environment, and feed those registrations into the resolved MCP catalog. An
app-server E2E will prove that selecting an executor plugin exposes and invokes
its tool on the owning executor.

Resume/fork semantics, dynamic environment replacement, and non-stdio
placement remain separate lifecycle decisions.

Validation

• just fmt
• cargo check --tests -p codex-plugin -p codex-core-plugins
• just bazel-lock-check
• git diff --check

Test targets were compiled but not executed locally; CI will run the test and
Clippy suites.

[jif-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8a69762b3a

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