Incorrect sampling decision propagated in some cases in span streaming

[sentrivana]

If the incoming decision is 0, we should always respect that and propagate a negative sampling decision (not talking about custom traces_samplers here). It looks like in some cases, when the sample_rand and sample_rate found in incoming baggage are inconsistent with the sampling decision, we instead take them into account.

[linear-code]

PY-2618

[sentry-pierre]

In sentry_sdk/tracing_utils.py, _make_sampling_decision handles inherited decisions differently from the old transaction model:

• Old model (tracing.py): when traces_sampler is undefined and parent_sampled is present, it uses parent_sampled directly as the sample rate (False → 0.0, immediately dropped).
• New span-streaming model (tracing_utils.py): when parent_sampled is present, it prefers propagation_context._sample_rate() from baggage. If that rate is positive, it recomputes sampled = sample_rand < sample_rate, which can override the incoming 0.

This means an incoming header with sampled=0 but sample_rate=1.0 and sample_rand=0.1 gets incorrectly sampled. The existing test_continue_trace_unsampled passes because sample_rand=0.999999 is already above sample_rate=0.5, so the bug is masked.

A maintainer can take it from here.