[codex] Centralize plugin auth capability filtering

[felixxia-oai]

Summary

This is the first step in making plugin auth routing consistent. The rule should not live as one-off checks in every place that loads or displays plugin capabilities.

This PR introduces a small resolver for the auth-level policy: given a plugin's declared apps, MCP servers, current auth mode, and active state, return the capabilities that are actually usable in that context.

Why

Product rule:

• SiWC auth can use app connectors, so app declarations stay available.
• API-key/direct auth cannot use app connectors, so app declarations are removed.
• When an active plugin has both an app and an MCP server with the same name, the app route wins for Codex-backed auth and the conflicting MCP server is hidden.

Putting that rule in capabilities.rs gives the rest of the stack one place to ask instead of duplicating auth checks in loader, manager, marketplace, and details code.

Validation

• cargo fmt
• cargo test -p codex-core-plugins

[felixxia-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 66f75a8dbd

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

[xl-openai]

I think this may be more than we need right now. The existing logic is small and only appears in two different flows, so I’d prefer to keep it local for now rather than introduce a shared resolver.

[felixxia-oai]

I think this may be more than we need right now. The existing logic is small and only appears in two different flows, so I’d prefer to keep it local for now rather than introduce a shared resolver.

I wanted this to be a layer where the routing logic lives. I'd like the end state to be if we wanted to change the filtering/routing logic in the future, we'd only need to change it in one place.

After the next PR in this stack #27958, this logic is used in 3 places so I think it'd be good to extract.