KiroCrew integration: render CAO MCP Apps and validate AG-UI interoperability

Parent: #580

## Goal

Reuse CAO's existing fleet UI inside KiroCrew by rendering CAO's SEP-1865 MCP Apps, then validate where AG-UI is needed for advanced event, approval, and generative UI behavior.

A custom KiroCrew App Kit dashboard should be a fallback only when a demonstrated requirement cannot be met through the existing MCP Apps or a focused AG-UI bridge.

## Proposed approach

Register CAO's MCP Apps-capable stdio server with KiroCrew's shared MCP gateway and render the existing CAO resources:

- `ui://cao/dashboard`
- `ui://cao/agent`
- `ui://cao/event-stream`

Validate `render_dashboard`, `render_agent_view`, event history/subscription, and `submit_command` through KiroCrew's inline and side-panel MCP Apps hosts.

CAO currently registers the MCP App resources through the MCP Apps plugin on `cao-mcp-server`. KiroCrew should use that process for the app surface while model-initiated external fleet management remains on `cao-ops-mcp`. The proof must determine whether KiroCrew can hide or safely ignore CAO's in-session tools when no `CAO_TERMINAL_ID` exists.

Separately exercise CAO's AG-UI surfaces to determine whether its six allow-listed `GENERATIVE_UI` components are already represented through the existing MCP App views or require a focused adapter.

## Scope

- Enable CAO's MCP Apps surface for the reference integration.
- Configure KiroCrew's shared MCP gateway and admit the CAO stdio server as poolable.
- Validate SEP-1865 capability negotiation and `ui://` resource loading.
- Validate inline and side-panel rendering, resizing, lifecycle, and app-to-tool callbacks.
- Validate live event behavior, history recovery, and one scoped mutation.
- Validate one approval or interrupt/resume journey.
- Exercise all six CAO generative UI component intents and document their behavior in KiroCrew.
- Identify the smallest owning-repository change for each demonstrated compatibility gap.

## Acceptance criteria

- [ ] KiroCrew negotiates `io.modelcontextprotocol/ui` with the CAO MCP server.
- [ ] `render_dashboard` renders `ui://cao/dashboard` in KiroCrew.
- [ ] `render_agent_view` renders `ui://cao/agent` for a selected CAO terminal.
- [ ] The event-stream view renders and receives live CAO lifecycle events.
- [ ] All three views work in KiroCrew's supported inline or side-panel presentation modes, with any host limitation documented.
- [ ] App-to-tool callbacks pass through KiroCrew's sandbox and CAO's `submit_command` authorization boundary.
- [ ] At least one permitted mutation succeeds and an insufficient-scope mutation is rejected clearly when auth is enabled.
- [ ] Event reconnect or rehydration does not leave a stale or duplicated fleet projection.
- [ ] One approval or interrupt can be resolved from KiroCrew and the same CAO session continues.
- [ ] Behavior of `approval_card`, `choice_prompt`, `diff_summary`, `progress`, `metric`, and `agent_card` is tested and documented.
- [ ] The integration either limits the exposed `cao-mcp-server` tools to the MCP Apps surface or documents a focused CAO change needed to do so.
- [ ] No custom KiroCrew App Kit dashboard is introduced unless a specific unmet requirement and rejected smaller alternative are recorded.

## Platform and security constraints

- Initial validation targets same-host macOS or Linux because KiroCrew's shared MCP gateway is stdio and Unix-socket based.
- Both CAO and KiroCrew feature gates must be enabled explicitly.
- CAO credentials and callback capabilities must remain within the existing server and sandbox boundaries.
- Remote CAO connectivity and Windows support are follow-ups.

## Non-goals

- Replacing the CAO Web UI.
- Building a second fleet-state model in KiroCrew.
- Expanding CAO's generative UI allow-list before compatibility is established.
- Building a custom KiroCrew dashboard without a demonstrated MCP Apps or AG-UI gap.

Start by inspecting CAO's MCP Apps registration on cao-mcp-server and KiroCrew's shared MCP gateway configuration, then run the same-host reference integration with both feature gates enabled. Validate the three ui:// resources, callbacks, event recovery, approval flow, and six generative UI intents. Done means the acceptance checklist is verified and any compatibility gaps are documented with their smallest owning-repository change.

Written by the indexing model from the issue text.