[Feat] Agent Plugins 1.0 support — package the CAO ecosystem as portable plugins + a plugin install/marketplace surface

## Overview

Adopt [Agent Plugins 1.0.0](https://agent-plugins.org/specification) — the open, vendor-neutral packaging standard for Agent Skills + MCP servers governed by a TSC drawing maintainers from AWS, Cursor, Microsoft, OpenAI, and Vercel ([source-of-truth repos](https://github.com/agentplugins): [spec](https://github.com/agentplugins/agent-plugins-spec) · [canonical example](https://github.com/agentplugins/agent-plugins-example) · [site](https://github.com/agentplugins/agent-plugins-site)) — in both directions:

1. **Author side** — publish the CAO ecosystem as Agent Plugins, so any [compatible client](https://agent-plugins.org/compatible-clients) (Kiro powers, VS Code, Cursor, GitHub Copilot, ChatGPT/Codex) can install one plugin and drive a CAO fleet.
2. **Client side** — teach CAO to install Agent Plugins through its existing managed-skills machinery.
3. **Marketplace surface** — a thin catalog (CLI + Web UI) over the client side: resolve → validate → install, no hosting.

CAO already has every ingredient the format standardizes: universal-format `SKILL.md` skills ([`skills/`](https://github.com/awslabs/cli-agent-orchestrator/tree/main/skills): `cao-session-management`, `cao-provider`, `cao-plugin`; built-ins in `src/cli_agent_orchestrator/skills/`), two stdio MCP servers (`cao-mcp-server`, `cao-ops-mcp`), managed-skills delivery per provider (docs/skills.md), and an external-integration story (docs/external-tool-integration.md) that today requires per-client documentation — exactly the packaging tax the standard removes. [Kiro powers now installs Agent Plugins natively](https://kiro.dev/blog/powers-supports-plugins/), so publishing to the standard gets CAO into the powers catalog for free.

## User Stories

- As an **operator using any compatible client** (Kiro, VS Code, Cursor, Copilot, Codex), I want to install one `cao` plugin so that my client gets the `cao-ops` MCP tools and the session-management skill and can install profiles, launch sessions, and message a running fleet — without CAO-specific setup docs for my client.
- As a **CAO maintainer**, I want to publish the ecosystem once against a public schema so that every compatible client is a distribution channel, instead of maintaining per-client integration guides.
- As a **CAO contributor**, I want the contributor skills (`cao-provider`, `cao-plugin`) packaged as a plugin so that my own coding agent loads CAO's extension conventions wherever I work.
- As a **CAO user**, I want `cao plugin add ` so that community Agent Plugins (skills + MCP servers published anywhere in the ecosystem) load into my CAO sessions through the existing per-provider delivery.
- As a **CAO user**, I want an installed-plugins view in the CLI and Web UI so that I can see, add, and remove plugins the way I manage flows and skills today.

## Acceptance Criteria

- `plugin.json` + `mcp.json` for the published `cao` plugin validate against the canonical [1.0.0 schemas](https://agent-plugins.org/schemas/1.0.0/plugin.schema.json) in CI on every PR.
- The `cao` plugin installs and works end-to-end in ≥2 compatible clients (Kiro powers + one of VS Code/Cursor/Copilot/Codex): `cao-ops` tools callable, `cao-session-management` skill discovered.
- Contributor plugin (`cao-provider` + `cao-plugin`, plus `cao-contributing` from #448 when it lands) validates and installs the same way.
- `cao plugin add` installs the [canonical example plugin](https://github.com/agentplugins/agent-plugins-example): its skill is delivered to a provider; an intentionally-invalid sibling skill is skipped with a report (spec failure isolation, §7.1); missing `skills/` tolerated (§6.2); a fatal `plugin.json` violation rejects the plugin before any component loads (§5.2).
- Installed plugins listed/removed via CLI and Web UI; install from a GitHub URL works.
- Naming decision — existing CAO event plugins (docs/plugins.md) vs. Agent Plugins — recorded and applied to docs before any public surface ships.
- Default posture unchanged: localhost-only `cao-server`, no credentials in package data (`env`/`headers` are visible package data per spec §9.2), containment (`./`-rooted paths) enforced on install.

## Proposed solution

**1. New top-level `plugin/` directory** (or `plugins/cao/` if 1b ships together) — the published Agent Plugin, following the [canonical example](https://github.com/agentplugins/agent-plugins-example) layout (directory name = manifest name, as it recommends):

```
plugin/
├── plugin.json # $schema …/1.0.0/plugin.schema.json · name "cao" · license Apache-2.0
├── skills/
│ └── cao-session-management/SKILL.md # existing skill, unchanged
└── mcp.json
```

```json
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
"mcpServers": {
"cao-ops": {
"type": "stdio",
"command": "uvx",
"args": ["--from", "git+https://github.com/awslabs/cli-agent-orchestrator.git@main", "cao-ops-mcp-server"]
}
}
}
```

*(Manifest is closed — no `hooks`, `agents`, `commands`, `mcpServers`, `lspServers` at `plugin.json` top level; the example repo calls these out explicitly. `command` must stay a single executable token with `args` separate; the `uv` prerequisite and the `cao-server`-on-`localhost:9889` prerequisite go in `description`/docs.)*

**2. New CI check** — schema validation of `plugin.json`/`mcp.json` against the pinned canonical schemas (no schema retrieval at load time, per §5.2).

**3. Extend the managed-skills machinery** (`src/cli_agent_orchestrator/` skills store + delivery) with an Agent Plugins loader:

- New `cao plugin add|list|remove` CLI group alongside `cao skills`.
- Loader implements the [client conformance floor](https://agent-plugins.org/client-implementers/conformance): manifest-first load, closed-schema validation, fixed-location discovery only (`skills/` immediate children, root `mcp.json`), narrow failure boundaries, report-and-continue.
- Skills route into the existing store + per-provider delivery (native `skill://` for Kiro CLI, prompt injection for Claude Code/Codex/Gemini/Kimi, `.agent.md` for Copilot) — only discovery changes.
- **Increment 1 is skills-only** — a skills-only client is conformant (§11.2). Increment 2 maps `mcp.json` entries into per-provider MCP config, supplying `PLUGIN_ROOT`/`PLUGIN_DATA` and expanding only those two placeholders in `args`/`env` values/`cwd` (§9) when CAO launches stdio servers.

**4. Web UI: installed-plugins panel** (parallel to flows/skills views) — list, add from URL/directory, remove.

**5. Migration executed additively**, per the example repo's workflow (add + validate `plugin.json` → move/copy skills → convert MCP config → keep client-specific concerns in extension namespaces → test before removing legacy). The example repo's [`migrate-agent-plugin` skill](https://github.com/agentplugins/agent-plugins-example/tree/main/skills/migrate-agent-plugin) can drive this — CAO's packaging PR dogfoods the ecosystem's own migration skill.

## Additional context

**Is your feature request related to a problem? Please describe.**
Every client that wants to drive CAO today needs its own integration path — docs/external-tool-integration.md for shell-callable skills, hand-written MCP config for `cao-ops-mcp`, per-provider skill delivery quirks. That's the publish-N-times tax Agent Plugins exists to remove: same knowledge, same tools, one package per client ecosystem. Meanwhile CAO can't consume the cross-client plugin supply now emerging (Kiro powers, VS Code, Cursor, Copilot, Codex all load the same format).

**Describe alternatives you've considered**

- *Kiro-power-only packaging* — reaches one client; the standard reaches five today and is where new capability lands first per Kiro's own launch post. Rejected.
- *Keep per-client integration docs* — status quo; scales linearly with clients and puts the burden on users. Rejected.
- *Package CAO profiles/flows as plugin components* — out of v1 scope; the spec defines exactly two component types (skills, MCP servers) and its manifest is closed. If profile distribution inside plugins is wanted later, it's a reverse-domain client-extension namespace (§8), or an upstream proposal in [agent-plugins-spec discussions](https://github.com/agentplugins/agent-plugins-spec/discussions) — not a CAO-local format fork.
- *Building trust/signing/registry features into the marketplace now* — the spec's [FUTURE_CONSIDERATIONS.md](https://github.com/agentplugins/agent-plugins-spec/blob/main/FUTURE_CONSIDERATIONS.md) explicitly leaves permissions, provenance/signatures, secrets handling, enterprise registries, and dependency resolution to future versions, with no committed timeline. CAO's catalog stays thin (resolve → validate → install) and inherits those capabilities when the standard defines them, rather than inventing CAO-local semantics that would need migrating.

**Additional context**

- **Naming reconciliation (blocking design note):** CAO already uses "plugins" for the observer-only Python event extensions in docs/plugins.md. Any public surface must disambiguate — e.g., "event plugins" (existing outbound hooks) vs. "agent plugins" (portable packages) — same class of collision as the node-fleet vs. agent-fleet note in #519.
- **Open design questions:** in-repo `plugin/` vs. dedicated repo (in-repo keeps chain-of-custody and CI validation simple); whether built-in protocol skills (`cao-supervisor-protocols`, `cao-worker-protocols`) belong in the portable package or stay runtime-internal; behavior when `cao-server` isn't running (clear error vs. self-start).
- **Relationship to #519:** separate track — #519 is AG-UI L2/L3 surfaces; this is packaging/distribution. They meet where an installed `cao` plugin gives any client the ops tools to drive the fleet those surfaces render.
- **Spec references:** [specification](https://agent-plugins.org/specification) (source: [spec/1.0.0.md](https://github.com/agentplugins/agent-plugins-spec/blob/main/spec/1.0.0.md), current published release per the spec repo README) · [plugin authors](https://agent-plugins.org/plugin-authors) · [client implementers](https://agent-plugins.org/client-implementers) · [Technical Charter](https://github.com/agentplugins/agent-plugins-spec/blob/main/GOVERNANCE.md) · [Kiro announcement](https://kiro.dev/blog/powers-supports-plugins/)