feat(tracing): Inject RN trace context into WebViews for connected traces

[antonis]

Outcome

A new opt-in integration/helper (e.g. packages/core/src/js/integrations/webview.ts, surfaced via packages/core/src/js/integrations/exports.ts) that injects the current RN propagation context into an allow-listed WebView, so the in-page @sentry/browser continues the RN trace.

Final API shape (helper vs. wrapper) per the outcome of the spike (#6779).

Acceptance criteria

• An error captured by @sentry/browser inside an allow-listed WebView, and the WebView's pageload transaction, carry the same trace_id as the RN app — on both New and Old Architecture and both iOS and Android.
• An allowedHosts gate: only listed hosts receive the injected context; non-listed pages are untouched (no trace/PII leakage to third-party pages).
• No-ops safely when react-native-webview is absent or JS is disabled on the WebView — never throws, never crashes the host app.
• Off by default (opt-in); no behavior change for users who don't add it.
• Unit tests added; yarn lint, yarn test, yarn circularDepCheck green; API report regenerated if the public barrel moved.

Out of scope

• Forwarding in-WebView browser events into the mobile session/project (separate, larger effort).
• Late injection / re-connecting in-WebView SPA (client-side) navigations after the entry pageload.
• Any @sentry/browser changes — v1 relies on the shipping meta-tag continuation.

References

• Meta-tag continuation contract (what v1 relies on): https://docs.sentry.io/platforms/javascript/tracing/distributed-tracing/

[linear-code]

RN-797