feat(observability): correlate MCP inspection outcomes with HTTP requests #5397

User Story

I use OpenShell L7 policy to permit or deny MCP requests. I need to connect an agent's tool attempt to OpenShell's actual inspection outcome.

Problem Statement

HTTP-level status alone does not explain bounded JSON-RPC/MCP inspection results, particularly when several messages share a request.

Impact / Why This Matters

Operators cannot tell which inspection stage rejected a request or distinguish message inspection from confirmed tool execution.

Proposed Design

Expose an inspection stage under the HTTP request with bounded message kinds, allowed identifiers and counts. Preserve privacy by excluding structured arguments, payloads and responses, and never present an inspected method as proof that the remote tool executed.

Suggested UX

Expand the inspected HTTP request to see its MCP inspection stage and match it to the same request ID in OpenShell security records.

Acceptance Criteria

• Allowed and denied inspections and multi-message counts correlate to the correct HTTP request.
• Arguments, payloads and response content are not exported; identifiers and counts remain bounded.
• Existing MCP enforcement semantics are unchanged, with no extra routine HTTP Activity record per inspected message.

Alternatives Considered

Agent-side tool telemetry is useful but cannot attest to OpenShell's independent decision. Full payload logging would expose sensitive content.

Agent Investigation

The local layer instruments existing JSON-RPC/MCP inspection points without expanding what the policy engine can authorize.

Component of #5210. This issue covers only mcp correlation; the tracking issue remains open for the other layers.

Checklist

• I've reviewed existing issues and the published docs.
• This is a design proposal, not a "please build this" request.