Fix baggage header merging and networkContext propagation in TracingURLSessionHandler

[Valpertui]

What and why?

TracingURLSessionHandler.modify() had two issues:

1. W3C baggage headers were not merged — when a request already had a baggage header, the handler skipped it entirely (same "do not overwrite" logic as trace propagation headers). Baggage headers should be merged instead, combining existing user-set values with SDK-injected ones (session.id, user.id, account.id).

2. networkContext parameter was ignored — the modify() method accepted a NetworkContext? parameter but never used it for populating rumSessionId, userId, and accountId in the TraceContext. It read exclusively from contextReceiver.context, so values provided via networkContext were never propagated into baggage headers.

How?

• Move BaggageHeaderMerger from DatadogRUM to DatadogInternal so it can be used by TracingURLSessionHandler.
• Add baggage header merging in modify(): when a writer produces a baggage header, merge it with any existing value using BaggageHeaderMerger instead of skipping.
• Use networkContext as the primary source for rumSessionId, userId, and accountId when creating the TraceContext, falling back to contextReceiver.context.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes
• Add Objective-C interface for public APIs - see our guidelines (internal)
• Run make api-surface when adding new APIs

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 21e6420a28

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Don’t return TraceContext when only baggage is injected

When a request already has W3C traceparent/tracestate set by the caller, this branch still sets hasSetAnyHeader = true after merging (or adding) baggage. That causes modify() to return a TraceContext, which NetworkInstrumentationFeature registers and later uses to build spans. The outgoing request keeps the caller’s original trace headers, so the span created from the returned TraceContext can end up on a different trace ID than the actual request, breaking distributed trace correlation whenever the app supplies its own trace headers but expects the SDK to only merge baggage. Consider tracking “trace header injected” separately from “baggage injected,” or avoid returning TraceContext when only baggage was modified.

Useful? React with 👍 / 👎.

[Valpertui]

I believe this is normal that there is a trace context returned if we inject any header.
But currently if at least 1 header doesn't get overwritten because it's already there (eg traceparent), we will propagate a traceContext with traceID and spanID set back to the SDK. While the network request sent will not contain those specific traceID/spanID, breaking distributed tracing in an unexpected way.

Sure it looks like a developer mistake to fix. But we need to remember that those header fields could also be set automatically by other integrations like Datadog.

Should we keep the current behavior? Should we revamp it ?