Mar Witek

Add user-facing tracing pipeline Adds a user-facing span pipeline to `foundations`, parallel to and independent of the existing internal tracing pipeline. Application code emits spans into a separate harness that exports OTLP over HTTP on a Unix domain socket, with per-trace routing metadata (an application-defined `RoutingMetadata`) attached to each span and carried to the endpoint in a configurable header, plus W3C `traceparent` continuation in and out. The public API lives in a dedicated `tracing::user_tracing` module that mirrors the top-level internal-tracing functions (`start_trace`, `span`, `add_span_tags!`, ...), plus a top-level `dual_span` that records into both pipelines at once; `#[span_fn(user = true)]` emits a dual span. The user span rides on `TelemetryContext`, so it propagates across `.await`, spawns, and hooks without manual threading. Two rules shape the surface: the user and internal pipelines are fully independent (separate harnesses, scope stacks, and exporters), and the public surface speaks W3C. Sampling is not configured inside foundations -- per-request activation is driven by the caller. Everything is gated behind the `user-tracing` cargo feature.

feat(telemetry): add deferred user span activation

Add an owned UserSpan handle for user tracing The user-tracing API is built around an ambient scope stack: `span()` parents under whatever is current and hands back an RAII guard that pops on drop. The scope stack is a `ThreadLocal` and its guard is deliberately `!Send`, so a span can never be held across an await point. That model can't express a per-request span in a service whose request pipeline is a state machine of separate callbacks rather than a call tree. The span outlives every individual callback, so there is no lexical scope for it to live in, and the only `Send` escape hatch available today is `into_context()` — which is meant for propagating into a future, and drags a snapshot of the whole ambient `TelemetryContext` along with it. `UserSpan` is an owned, `Send` handle to a user span, detached from the scope stack. It can live in a struct field, cross threads, and be finished in a different callback from the one that started it. The span is reported when the last reference to it drops. That is normally the handle, though `enter()` takes its own, as does any context built from the resulting scope. Parents are named explicitly rather than inferred from a stack, because spans in a callback-driven pipeline overlap without nesting: an upstream fetch can still be unfinished while response-side work that is not part of it is running, so "innermost active span" is the wrong parent. A handle is always usable — there is no `Option`. When no trace is active, or it wasn't sampled, or no pipeline is configured, the handle is inactive: tagging does nothing, children are inactive in turn, nothing is reported. This keeps `if let Some(span)` out of call sites, and mirrors how cf-rustracing's own inactive spans already behave. `user_tracing::start_trace` and `w3c_traceparent` are re-expressed on top of the new type, and `create_user_span` now shares its child-construction with `UserSpan::child`, so each behaviour has a single implementation. `enter()` bridges back to the ambient API for callers that prefer it. Purely additive: no existing caller changes. `Tag` is now re-exported, since it appears in the `set_tags` bound.

refactor(telemetry): distinguish deferred user spans

Add SpanContext::toTraceparent()

feat(telemetry): attach user spans to contexts

Correct the UserSpan lifetime docs The type claimed the span is reported when the handle is dropped. It is reported when the last reference drops

Collapse duplicate span write-lock matches onto with_write `write_current_span` and `write_current_user_span` each open-coded the same three-way match over `SharedSpanHandle` to obtain a write guard, including an `unreachable!` arm for the inactive case. `SharedSpanHandle::with_write` already does exactly this, so both now call it. The cached `is_sampled` check stays in front of both. Writing to an unsampled span is a no-op regardless, since an unsampled span is `Span(None)`, but the flag is stored outside the lock precisely so the common path doesn't have to take a write guard to discover there is nothing to do. The inactive arm becomes a no-op rather than a panic. It remains unreachable either way: a handle can't be `Inactive` when `is_sampled` is true. `with_write` loses its `user-tracing` cfg now that an unconditional caller uses it.

[Workers] Add release note for v8 version 15.3 update (#33078)