A2A agent operations not captured in Grafana observability dashboard

## Summary

A2A agent API calls (`/api/agents/*`) are invisible in the Grafana analytics dashboard. The dashboard exclusively queries MCP proxy metrics (`mcp_tool_executions_total`, `mcp_auth_requests_total`), which are emitted for MCP server traffic only. Agent operations like discover, health check, list, and get are not tracked in any Prometheus counter, making it impossible to monitor A2A usage patterns, error rates, or performance by agent name.

## Current Behavior

All `/api/agents/*` calls pass through `RegistryMetricsMiddleware` but:

1. **Middleware** (`registry/metrics/middleware.py:64-86`) -- `extract_operation_info()` recognizes `servers`, `search`, `health`, `auth` but **not `agents`**. Agent calls fall through as `resource_type="unknown"`, losing the agent name and operation type.

2. **Metrics service processor** (`metrics-service/app/core/processor.py:113-135`) -- Routes `AUTH_REQUEST`, `TOOL_DISCOVERY`, `TOOL_EXECUTION`, `PROTOCOL_LATENCY`, `HEALTH_CHECK` to OTEL counters. `REGISTRY_OPERATION` type (defined in `metrics-service/app/core/models.py:11`) has **no handler** -- metrics are silently dropped before reaching Prometheus.

3. **Grafana dashboard** (`grafana/dashboards/mcp-analytics-comprehensive.json`) -- All panels query `mcp_tool_executions_total` or `mcp_auth_requests_total` by `server_name`. No panels exist for agent operations.

## Expected Behavior

A2A agent operations should be observable in the Grafana dashboard with per-agent-name granularity:
- Agent discover calls (by-skills, semantic) with success/failure rates
- Agent health checks by agent name
- Agent list/get operations
- Response time distributions per agent operation

## Proposed Implementation

### 1. Registry middleware (`registry/metrics/middleware.py`)

Add `agents` path parsing to `extract_operation_info()` (~5 lines):

```python
elif path_parts[1] == "agents":
resource_type = "agent"
if len(path_parts) >= 3:
resource_id = path_parts[2]
if method == "GET" and len(path_parts) == 2:
operation = "list"
elif "discover" in path:
operation = "discover"
elif "health" in path:
operation = "check"
elif "toggle" in path:
operation = "toggle"
```

### 2. Metrics service

**Option A (new metric type):** Add `AGENT_OPERATION` to `MetricType` enum, create a dedicated OTEL counter (`a2a_agent_operations_total`) with labels `agent_name`, `operation`, `success`, and add processor routing. This keeps A2A metrics cleanly separated from MCP metrics.

**Option B (reuse existing):** Add a processor handler for the existing `REGISTRY_OPERATION` type with an OTEL counter. Agent calls would flow through as `registry_operation` with `resource_type=agent`. Simpler but mixes agent metrics with other registry operations.

Recommended: **Option A** -- enables dedicated Grafana panels with agent-specific labels.

Files to modify:
- `metrics-service/app/core/models.py` -- add enum value
- `metrics-service/app/otel/instruments.py` -- add counter + histogram
- `metrics-service/app/core/processor.py` -- add routing handler

### 3. Grafana dashboard

Add panels to `grafana/dashboards/mcp-analytics-comprehensive.json`:
- "A2A Agent Operations" bar chart (by agent name)
- "Agent Discovery Success Rate" gauge
- "Agent Health Check Status" table
- "Agent Response Time P95" time series

## Impact

Without this fix, operators have no visibility into A2A agent usage patterns, cannot detect agent-specific failures, and cannot measure A2A adoption. The MCP server metrics create a false impression of complete observability while A2A traffic is a blind spot.

## Related

- The `REGISTRY_OPERATION` metric type already exists in `models.py:11` but is never processed -- this should either be wired up or removed to avoid confusion.