Port browser-integration-tests to span streaming

Port dev-packages/browser-integration-tests to span streaming. Span streaming is the default, so every suite that still pins traceLifecycle: 'static' covers behaviour we no longer ship.

Part of SDK-1425, one tracking issue per integration test package.

Scope

• 315 traceLifecycle: 'static' pins across 299 files
• 62 test.ts files call waitForTransactionRequest and need a real rewrite
• 36 suites already have a -streamed twin, and 32 of those still sit next to the static original
• The remaining ~226 pinned files never assert on a transaction, so they only need the pin removed

How to port a suite

1. Remove the traceLifecycle: 'static' pin from the suite's init.js (and any subtest init).
2. If a -streamed twin exists, fold it back: delete the static original and rename the twin to the base name. Do not keep both, or the coverage doubles and the two copies drift.
3. Rewrite the assertions from transaction envelopes to span v2 using utils/spanUtils.ts:
   • waitForTransactionRequest becomes waitForStreamedSpan / waitForStreamedSpans
   • waitForStreamedSpanEnvelope gives the raw envelope when a test asserts on envelope headers
   • event.transaction becomes span.name
   • contexts.trace.op becomes the sentry.op attribute plus span.is_segment
   • contexts.trace.data['x'] becomes span.attributes['x'], which has the shape { value, type }
   • transaction_info.source becomes the sentry.segment.name.source attribute
4. Streamed child spans arrive across several envelopes, so collect across envelopes wherever a test asserts on children of a segment span.

Watch for span names that become low cardinality under streaming: pageload, navigation, resource, http.client and web vitals. Those assertions change, not just the helper.

Keep static trace lifecycle coverage

Do not add a -static copy per suite. The profiling/traceLifecycleMode_* suites already exercise both lifecycles. Pick one tracing suite to keep on the static pin as a guard and say so in the PR.