feat(correlation): propagate request ID and trace context across all legs

[cdoern]

Problem

A single AI request reaches the backend over two paths:

• forwarded — the client's request, proxied upstream
• delegated — callouts the proxy originates itself while handling it (Files API metadata and content fetches)

Neither carried trace context. The two legs arrived at the backend as unrelated traffic, so a slow or failing request could not be attributed to a layer.

Change

A shared TraceContext resolves x-request-id and a W3C traceparent once per downstream request, and both are stamped onto every leg:

• New trace_context filter propagates them to the forwarded request.
• Delegated callouts inject them unconditionally, outside the operator-configured forward_headers allowlist — correlation that depends on per-filter configuration silently goes missing.

Each leg draws its own span-id from the shared trace-id, which is what keeps delegation latency separable from inference latency.

Notes for review

Identifier resolution reads extra_request_headers, not just downstream headers. The request_id builtin writes its generated ID there rather than back into ctx.request.headers. A downstream-only lookup finds an ID only when the client happened to supply one — and silently no-ops otherwise, which is the common case. There is a test named for it.

Agreement across hops goes through request extensions, not header inspection. Delegated callouts can run in the StreamBuffer pre-read phase, ahead of header-phase filters, where injected values are not visible. Whichever hop resolves first initializes the shared context; later hops reuse it regardless of filter order. An earlier header-based attempt produced two different trace-ids for one request, caught by the integration test in this PR.

Client-supplied traceparent values are validated and discarded when malformed rather than forwarded into the telemetry backend unchecked.

One assertion was deliberately relaxed. The delegated callouts of one request share a span, because correlation is resolved once at the filter boundary — file resolution is one delegation hop regardless of how many files it fetches. The test asserts that instead of per-callout spans, and that the forwarded leg's span is disjoint from it. Happy to switch to per-callout spans if reviewers prefer.

Incidental improvement: the callout header set is now built once per request instead of once per callout, removing repeated allowlist copies for requests that resolve several file references.

Scope

Trace context is propagated but not yet exported — no OpenTelemetry pipeline exists in this repo, so these headers make requests correlatable without producing spans. Wiring an exporter, covering delegated MCP calls, and recording a delegation-latency metric remain to be done.

Testing

• 9 unit tests for identifier resolution and traceparent validation, including a table of malformed inputs
• 7 unit tests for the trace_context filter
• 2 integration tests over the example config asserting both legs share a trace-id under distinct spans, for generated and client-supplied traces
• Example config examples/configs/trace-context.yaml, generated filter docs, full workspace suite and clippy -D warnings clean

[praxis-bot-app]

Unsigned commits: ca5fa2d. Please sign your commits.

[praxis-bot]

Review Summary

Clean, well-documented feature with thorough test coverage. The module-level doc in correlation/mod.rs is excellent -- the resolution precedence and the agreement-across-hops rationale are exactly what a future maintainer needs. Three medium-severity items below.

Severity	Count
Critical	0
Large	0
Medium	3

[leseb]

Good direction, thanks @cdoern