feat(observability): distinguish HTTP response selection from delivery failure #5398

User Story

I run OpenShell workloads that consume streaming HTTP responses. I need to distinguish a selected successful response from a body that was truncated, cancelled or blocked later.

Problem Statement

Accepting response headers does not establish that the response body reached the workload completely or that the downstream operation completed.

Impact / Why This Matters

A 200 response can appear successful even when delivery fails after headers, obscuring partial data and late response-middleware denials.

Proposed Design

Track response delivery separately from policy and response selection. Keep one primary HTTP Activity record and emit an additional correlated record only for a failure after that record. Preserve the distinction between OpenShell-observed delivery and any downstream application result.

Suggested UX

A request can show an upstream 200 alongside a failed delivery stage. Its exceptional security record identifies the same request and the stage that observed the problem.

Acceptance Criteria

• Complete, truncated, cancelled, client-disconnected and late middleware-denied deliveries are distinguishable with bounded byte/outcome metadata.
• Routine successful requests still produce only one primary HTTP Activity record; post-header failures produce a correlated exception record.
• No receipt or status claims complete downstream execution, and existing typed denial and streaming behavior is preserved.

Alternatives Considered

Waiting to log every request until the entire body completes delays routine audit visibility. Logging success from headers alone loses late failures; always adding a second record increases unsampled volume.

Agent Investigation

This is the final and largest layer. Much of its raw diff moves existing response tests into a separate tests module; delivery-state and streaming changes still warrant separate review.

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