[FEATURE]: Add observability and audit for extension calls

[vishu-bh]

Parent epic: #2527

User Story

As an operator, I want extension discovery, advertisement, routing, proxying, handler execution, resource serving, sanitizer decisions, plugin decisions, and denials to be observable and auditable so that extension behavior can be monitored and investigated.

One-Week Deliverable

Add structured logs, audit events, metrics, and tracing attributes for generic extension operations.

Acceptance Criteria

• Discovery records extension identifier, gateway id, source, and enabled state without logging secrets.
• Capability advertisement records extension id, caller scope category, client support, outcome, and deny reason where applicable.
• Method routing records extension id, method, routing mode, gateway id or handler, outcome, latency, and auth scope category.
• Denied extension calls produce security/audit events.
• Plugin blocks, sanitizer blocks, disabled extension denials, unknown method denials, and hidden gateway denials are distinguishable.
• MCP Apps-specific events include AppBridge allowed/denied calls, cross-server denials, CSP/sandbox policy decisions, and external navigation/linkout decisions.
• Metrics distinguish core MCP methods from extension methods.
• Observability follows existing separate-session behavior where applicable.
• Tests cover audit/log emission for allow and deny paths.

Demo

Call a Tasks-style extension method and a denied unknown method, then show trace/log/audit output for both. Also show an MCP Apps external-navigation denial event.

[caioribeiroclw-pixel]

This acceptance criteria looks right. One concrete shape that has worked for me when thinking about MCP/extension observability is to keep three outputs separate:

1. audit event for forensics/compliance
2. structured log for debugging a failed route/handler
3. low-cardinality metric for dashboards/alerts

For this issue, I’d probably make the allow + deny paths emit the same event envelope, with only redacted shapes:

{
  "event": "extension.method_call",
  "request_id": "...",
  "session_id": "...",
  "gateway_id": "...",
  "extension_id": "tasks",
  "method": "tasks.create",
  "routing_mode": "proxy|handler|denied",
  "handler": "...",
  "auth_scope_category": "read|write|admin|unknown",
  "status": "ok|denied|error|timeout",
  "latency_ms": 123,
  "args_shape": { "fields": ["title", "due_date"], "redacted": true },
  "result_shape": { "kind": "task", "count": 1, "redacted": true },
  "error_class": null
}

Then metrics can stay much smaller, e.g. labels only for extension_id, method_family or method_type, routing_mode, status, and maybe auth_scope_category — not raw method args/results/user identifiers.

For the demo criterion, the useful assertion is probably:

• allowed Tasks-style method emits audit/log/trace with status=ok
• denied unknown method emits audit/log/trace with status=denied
• neither output contains secret-like values or raw payloads
• metrics distinguish core MCP methods from extension methods without high-cardinality labels

I also published a tiny runnable receipt demo for this exact audit/logging split if it helps as a reference shape, no dependency on adopting it:

npx --yes pluribus-context@latest demo mcp-audit-receipt

The important bit is the boundary: audit enough to answer “who/what/which scope/what outcome”, but avoid turning observability into a second copy of sensitive tool payloads.