CLAUDE_CODE_PROPAGATE_TRACEPARENT=1 does not inject traceparent header into outbound LLM requests

## Problem

When `CLAUDE_CODE_PROPAGATE_TRACEPARENT=1` is set, Claude Code emits client-side OTLP spans (`claude_code.interaction`, `claude_code.llm_request`) but does not inject a W3C `traceparent` header into the outbound HTTP requests to the LLM API. This means any OTLP-capable server (an API gateway, an observability proxy, etc.) creates its own trace rather than becoming a child span of Claude Code's client trace.

## Observed behavior

- `CLAUDE_CODE_ENABLE_TELEMETRY=1` + `CLAUDE_CODE_PROPAGATE_TRACEPARENT=1` + `OTEL_TRACES_EXPORTER=otlp`
- Client spans export correctly via OTLP
- Server spans from the upstream API have a different `trace_id` than the client spans
- No `traceparent` header appears on the outbound HTTP request (verified by checking `http.request.header.traceparent` on the server span — absent)

## Expected behavior

With `CLAUDE_CODE_PROPAGATE_TRACEPARENT=1`, the outbound HTTP request to the LLM API should carry a `traceparent` header derived from the active span context, per the [W3C Trace Context spec](https://www.w3.org/TR/trace-context/). The server then creates a child span linked to the client's trace, producing a single connected trace.

## Why this matters

Without traceparent propagation, client and server spans are disjoint traces. The only way to correlate them is by content + timing, which is fragile and breaks in concurrent workloads. This is the standard mechanism for distributed tracing across service boundaries, and the flag name suggests it's intended to work.