refactor(api,dashboard-api): Allow traceparent propagation into API

[ben-fornefeld]

Summary

• stop stripping incoming traceparent in the API tracing middleware
• extract remote trace context before starting the server span so caller trace IDs propagate through API spans
• allow traceparent, tracestate, and baggage through API and dashboard-api CORS headers

[cursor]

PR Summary

Medium Risk
Changes how incoming trace context is extracted and propagated, which can affect distributed tracing correlation and potentially allow user-supplied trace headers to influence span linkage. Functional behavior of the APIs should be unchanged, but observability and debugging workflows may shift.

Overview
Enables end-to-end distributed tracing by propagating incoming W3C trace context (traceparent/tracestate and baggage) through API and dashboard-api requests. The tracing middleware now extracts remote context from request headers before starting the server span (instead of stripping traceparent), and both services’ CORS configs now explicitly allow the OpenTelemetry context propagation headers via telemetry.ContextPropagationHeaders().

^{Reviewed by Cursor Bugbot for commit 044e2f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

LGTM — clean, well-tested observability change.

Extended reasoning...

Overview

This PR modifies the Gin OTel tracing middleware to extract W3C trace context from incoming requests (instead of stripping it), starts server spans as children of the remote parent, and allows traceparent/tracestate/baggage through CORS in both the API and dashboard-API. A new regression test covers the propagation path.

Security risks

Accepting caller-provided trace context means external clients can influence which trace ID their requests appear under. This is standard, expected behavior for W3C traceparent — the server still creates its own span; it simply links it to the caller's trace. There is no auth bypass, data exposure, or business logic impact. The baggage header is also accepted via CORS; if downstream code ever reads baggage values for business decisions this would warrant scrutiny, but that is not the case here.

Level of scrutiny

Low. The change touches only telemetry/observability code and CORS header allow-lists. It follows established OpenTelemetry conventions, has no effect on request authorization or data handling, and includes a targeted test.

Other factors

The test in middleware_test.go covers the core invariant (span is a child of the remote parent and carries the correct trace ID). No prior review comments exist. Bug hunting found no issues.

[djeebus]

We won't necessarily be using this one:

Suggested change

	var contextPropagationHeaders = NewTextPropagator().Fields()
	var contextPropagationHeaders []string
	func init() {
	contextPropagationHeaders = otel.GetTextMapPropagator().Fields()
	}