test: Add streaming integration tests

[sentrivana]

Description

Will need #6757

Issues

Part of #5395

Reminders

• Please add tests to validate your changes, and lint your code using uv run ruff.
• Add GH Issue ID & Linear ID (if applicable)
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[sentry-warden]

Streaming span payload accessed with wrong key "transaction" instead of attributes["sentry.segment.name"]

In test_continue_trace_span_streaming, the falsy-branch asserts trace1_payload["transaction"] == "hi", but streaming span envelopes use the _to_json() format which has "name", not "transaction". The else-branch of the same test correctly uses trace1_payload["attributes"]["sentry.segment.name"], making the falsy-branch a copy-paste error that will raise KeyError at runtime.

Evidence

• StreamedSpan._to_json() (traces.py:592) produces a dict with keys "name", "trace_id", "attributes", etc., but no top-level "transaction" key.
• test_continue_trace_span_streaming uses capture_envelopes, so trace1.items[0].payload.json is the raw _to_json() output.
• The else-branch of the same test correctly accesses trace1_payload["attributes"]["sentry.segment.name"], confirming the expected format.
• The non-streaming counterpart test_continue_trace calls trace1.get_transaction_event() which does return a "transaction" key — this is the source of the copy-paste.

_{Identified by Warden code-review}

[sentry-warden]

span2 segment assertions accidentally check span1

The last two assertions in the span2 block reference span1 instead of span2, so span2's sentry.segment.id/sentry.segment.name attributes are never actually validated.

Evidence

• Lines 88-89 assert span2["status"] and span2["name"], correctly targeting span2.
• Lines 90-91 then assert span1["attributes"]["sentry.segment.id"] and span1["attributes"]["sentry.segment.name"], duplicating the span1 checks at lines 84-85.
• span2's segment attributes are therefore never asserted, leaving that edge case uncovered.

_{Identified by Warden code-review · M3R-3T2}

[sentry-warden]

expected_baggage uses literal %%20 in f-string context

This value is built with f-strings (no %-formatting applied), so Head%%20SDK%%20tx stays literal and won't match the single-percent Head%20SDK%20tx produced by baggage.serialize(), failing the assertion.

Evidence

• The original non-streaming test at line ~332 uses %-string formatting (... % (trace_id, sample_rate, ...)), where %% correctly collapses to %.
• Here the string is assembled purely from f-strings/plain literals with no % operator, so %%20 remains two literal percent signs.
• assert baggage.serialize() == expected_baggage compares against a URL-encoded value that emits single %20.

_{Identified by Warden code-review, find-bugs · 95K-D3H}

[sentry-warden]

trace2.headers access raises AttributeError in streaming test

trace2 is a payload dict from capture_items (item.payload.json), which has no .headers attribute, so this assertion will raise AttributeError instead of testing DSC headers; the envelope/item headers need to be captured separately.

Evidence

• capture_items fixture (tests/conftest.py:376) stores items as UnwrappedItem where payload = item.payload.json (a dict).
• The test unpacks trace1, message, trace2 = [item.payload for item in items], so trace2 is a dict, not an envelope.
• trace2.headers["trace"] on a dict raises AttributeError.
• The original test_continue_trace (line 179) used capture_envelopes, where trace2 was a full envelope object exposing .headers.

_{Identified by Warden code-review · EFA-YRW}