feat(observability): correlate inspected HTTP requests with traces and OCSF #5393

User Story

I run OpenShell sandboxes that call protected HTTP APIs. I need to connect each inspected request to its enforcement decision and security record when investigating an agent operation.

Problem Statement

Trace export and OCSF trace fields alone do not provide a shared per-request receipt across the caller, OpenShell enforcement spans and HTTP Activity records.

Impact / Why This Matters

Matching by timestamps is ambiguous when requests overlap. A policy denial must remain distinguishable from a request that reached the API.

Proposed Design

Use bounded W3C context only for correlation, not identity. Give each inspected request an OpenShell-generated ID shared by enforcement spans, the HTTP Activity record and a protected response header. Keep one primary HTTP Activity record, including pre-response failures; retain separate security findings.

Suggested UX

An HTTP client sends traceparent; the inspected response carries X-OpenShell-Request-ID. Operators join it to OCSF metadata.correlation_uid. Uninspected traffic is outside this contract.

Acceptance Criteria

• Allowed, denied and pre-header failure paths share the correct request ID and produce one primary HTTP Activity record.
• Malformed, duplicate and unsampled trace context has bounded, documented behavior; caller or upstream headers cannot forge the receipt.
• Existing OCSF trace profiles and sampling rules remain consistent, and telemetry failure cannot change enforcement.

Alternatives Considered

Timestamp joins are insufficient. A middleware service cannot consistently observe requests denied before middleware or protect receipts across every inspected response.

Agent Investigation

The local prototype reuses the existing middleware request UUID and upstream #4789 OCSF context extraction. It adds request and policy-stage spans, without a new gateway RPC or Relay dependency.

Component of #5210. This issue covers only http 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.