feat: MCP tool completeness — expose all REST endpoints as MCP tools

[OneStepAt4time]

M1.1 — Tool Completeness

Parent: #440 (Roadmap)
Milestone: M1 — MCP Server Complete
Blocks: M1.2, M1.3, M1.4

Context

src/mcp-server.ts currently exposes only 5 tools. The REST API has 17+ endpoints. Users of the MCP server can only do basic session CRUD — they can't approve permissions, kill sessions, read panes, or manage pipelines.

Tools to add

P0 (session lifecycle):

• kill_session — DELETE /v1/sessions/:id
• approve_permission — POST /v1/sessions/:id/approve
• reject_permission — POST /v1/sessions/:id/reject
• server_health — GET /v1/health

P1 (session interaction):

• send_bash — POST /v1/sessions/:id/bash (legacy)
• send_command — POST /v1/sessions/:id/command (legacy)
• escape_session — POST /v1/sessions/:id/escape
• interrupt_session — POST /v1/sessions/:id/interrupt
• capture_pane — GET /v1/sessions/:id/pane

P2 (advanced features):

• get_session_metrics — GET /v1/sessions/:id/metrics
• get_session_latency — GET /v1/sessions/:id/latency
• batch_create_sessions — POST /v1/sessions/batch
• list_pipelines — GET /v1/pipelines
• create_pipeline — POST /v1/pipelines
• get_swarm — GET /v1/swarm
• get_session_summary — GET /v1/sessions/:id/summary

Acceptance criteria

• All P0 + P1 tools implemented and working
• Each tool has proper inputSchema with Zod validation
• Error handling consistent with REST API
• aegis-bridge mcp exposes all tools via tools/list

How to approach

⚠️ Use plan mode + brainstorming skill. The existing 5 tools follow a clear pattern — replicate it for the new ones. Don't change the AegisClient class architecture.