[Feature]: Add enable/disable controls for discovered skills, plugins, and MCP servers

### Problem or use case

When working with multiple agents and projects in Orca, I often do not want every installed skill, plugin, or MCP server enabled all the time.

Different projects need different sets of tools. Temporarily disabling unused customizations can also reduce clutter and prevent agents from seeing tools that are irrelevant to the current task.

Today this usually requires going into provider-specific configuration files or uninstalling or moving something that I only want to disable temporarily.

What I would like is simple:

**Keep agent customizations installed, but make them easy to enable or disable from Orca.**

A UI similar to the Codex/VS Code Plugins view is close to the workflow I have in mind: installed customizations are visible in one place and can be quickly turned on or off.

#### Orca already has runtime-aware discovery

Orca already has code for discovering agent-side skills, separate from Orca's own plugin system.

For example, the current skill discovery implementation scans provider-specific locations including:

* `~/.codex/skills`
* `~/.claude/skills`
* `~/.agents/skills`
* `~/.codex/plugins/cache`
* OpenCode, Grok, Pi, OMP, Gemini, Cursor, and other agent skill directories
* repository-level `.agents/skills` and `.claude/skills`

See:

[https://github.com/stablyai/orca/blob/v1.4.179/src/main/skills/skill-discovery-sources.ts](https://github.com/stablyai/orca/blob/v1.4.179/src/main/skills/skill-discovery-sources.ts)

Orca also already has a UI implementation for displaying discovered skills by provider and source:

[https://github.com/stablyai/orca/blob/v1.4.179/src/renderer/src/components/skills/SkillsPage.tsx](https://github.com/stablyai/orca/blob/v1.4.179/src/renderer/src/components/skills/SkillsPage.tsx)

That page does not appear to be exposed through normal navigation in v1.4.179, but the underlying runtime-aware discovery already exists.

For MCP servers, Orca also already inspects MCP configuration and recognizes enabled/disabled state:

[https://github.com/stablyai/orca/blob/v1.4.179/src/shared/mcp-server-inspection.ts](https://github.com/stablyai/orca/blob/v1.4.179/src/shared/mcp-server-inspection.ts)

So a good part of the discovery and inspection layer already seems to exist. The missing part is a user-facing way to manage the enabled state of these agent customizations.

### Proposed solution

Add a runtime-aware management surface for agent customizations.

This could be exposed as something like **Agent Customizations**, with sections or filters for Skills, Plugins, and MCP servers.

Where applicable, each item could show:

* Type: Skill / Plugin / MCP
* Provider
* Source
* Scope: Global / Workspace
* Runtime: Local / WSL / SSH
* Enabled / Disabled state

Items whose provider supports enable/disable should have a toggle.

#### Use provider-native controls where possible

Orca should preferably use each provider's native configuration mechanism instead of moving files or uninstalling components.

Codex is a good first target because it already separates installed and enabled plugin state.

For example:

```toml
[plugins."plugin@marketplace"]
enabled = false
```

Codex also has dedicated code for changing this state while preserving the rest of the configuration:

[https://github.com/openai/codex/blob/main/codex-rs/config/src/plugin_edit.rs](https://github.com/openai/codex/blob/main/codex-rs/config/src/plugin_edit.rs)

Its plugin model also tracks the capabilities contributed by a plugin, including skills and MCP servers:

[https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/manager.rs](https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/manager.rs)

This seems preferable to Orca inventing its own filesystem-based disable mechanism.

For standalone skills or providers that do not expose a native disabled state, Orca could initially show them as read-only rather than rename or move files behind the user's back.

Support can then be added incrementally per provider.

#### Respect the actual agent runtime

The enabled state should be resolved and changed in the runtime where the agent actually runs.

For example, if:

* Orca is running on Windows
* the workspace runtime is WSL
* Codex runs inside WSL

then Orca should manage the relevant WSL-side Codex configuration, not the Windows-side `~/.codex`.

The same principle should apply to SSH environments.

This is especially important because Orca's existing skill discovery is already runtime-aware. The management layer should follow the same runtime ownership.

#### Keep enable/disable separate from uninstall

Disabling a customization should not require:

* uninstalling a plugin
* renaming or moving a skill directory
* rewriting unrelated configuration
* silently modifying shared project configuration

If a project-level configuration must be changed, the UI should make that scope clear before applying the change.

#### Suggested first iteration

This does not need to support every agent immediately.

A useful first version could:

1. Show discovered agent customizations for the active runtime.
2. Read and toggle native Codex plugin enabled state.
3. Show the enabled/disabled state of MCP servers Orca already knows how to inspect.
4. Allow MCP toggling where the underlying provider or config format supports it safely.
5. Show standalone skills even if some are initially read-only.
6. Indicate whether a change applies immediately, after reload, or only to new agent sessions.

That would already solve the main workflow without requiring Orca to own the entire plugin or MCP ecosystem.

#### Acceptance criteria

* Agent customizations are discovered against the active Orca runtime.
* Supported customizations can be disabled without uninstalling them.
* Codex plugin enabled state can be read and changed through its native configuration mechanism.
* Local, WSL, and SSH runtimes do not accidentally modify another host's configuration.
* Existing unrelated configuration and credentials are preserved.
* Project/global scope is visible to the user.
* The UI indicates when a reload or new session is required.
* Unsupported providers can remain read-only rather than using destructive workarounds.

### Alternatives or additional context

There are related MCP requests, but they address different problems.

#10132 focuses on first-class MCP configuration in Orca.

#7362 proposes an Orca MCP Bridge shared across agents.

Neither is required for this feature.

The core request here is narrower:

**Let users see and quickly enable or disable the skills, plugins, and MCP servers used by their agents, using the active runtime and the provider's native mechanisms where available.**

A new marketplace, a shared MCP bridge, support for every provider, and universal hot-reload can all remain out of scope for the initial version.

Start by reading src/main/skills/skill-discovery-sources.ts, src/renderer/src/components/skills/SkillsPage.tsx, and src/shared/mcp-server-inspection.ts to trace discovery, UI exposure, and runtime-aware inspection. Map the first supported management slice against the acceptance criteria, including active-runtime ownership, native Codex state, scope visibility, and unsupported read-only items. Done means the supported states can be safely viewed and changed without affecting another runtime or unrelated configuration.

Written by the indexing model from the issue text.