Investigate and fix trace propagation behaviour when ignoring spans

[Lms24]

When span streaming is enabled, the ignoreSpansoption has an influence on how we propagate traces to downstream services.

Scenario: An incoming trace is sampled positively. The current SDK is configured for span streaming.

Cases:

• Segment span is ignored: the SDK should propagate a negative sampling decision to ending up with a trace where the current SDK's segment is entirely missing but downstream services would sample positively.
  • This is analogous to using tracesSampler and returning 0 instead of using samplingContext.inheritOrSampleWith(0).
• Child span is ignored: the SDK should propagate the segment's (i.e. positive) sampling decision. This also applies when http.client spans themselves are ignored.

Currently, this is untested behaviour. We need to write tests and apply fixes if the actual behaviour diverges.

[linear-code]

JS-3042

[sentry-pierre]

I checked the streaming ignoreSpans paths in packages/core/src/tracing/trace.ts and the propagation logic in packages/core/src/utils/traceData.ts.

Findings:

• Ignored segment spans: trace.ts sets them as active, and because SentryNonRecordingSpan always carries TRACE_FLAG_NONE, getTraceData() naturally propagates a negative (-0) decision. This matches the expected behavior.
• Ignored child spans inside startSpan: trace.ts does not set ignored child spans as active, so getTraceData() falls back to the parent segment span and propagates its positive decision. This also matches expectations.
• The divergence: Instrumentations that explicitly pass the span to getTraceData()—notably packages/core/src/fetch.ts (and similarly Kafka/AMQP)—pass the ignored SentryNonRecordingSpan directly. getTraceData() reads its TRACE_FLAG_NONE and propagates -0 to downstream services instead of the segment’s positive decision.

So there’s a concrete bug in the explicit-span propagation path, and there are currently no tests asserting propagation headers for ignored spans.