feat(react-native): Add NetworkRecordingOptions and network sanitizer

[beekld]

Summary

Ports NetworkRecordingOptions and the network sanitizer from highlight-run into
@launchdarkly/observability-react-native, wiring them up to the existing OpenTelemetry
FetchInstrumentation and XMLHttpRequestInstrumentation via the applyCustomAttributesOnSpan
hook.

When recordHeadersAndBody is enabled, the SDK will add sanitized request/response headers
(and response bodies for XHR, request bodies for string fetch bodies) as attributes on the HTTP
spans that OTel already creates. Sensitive headers (authorization, cookie,
proxy-authorization, set-cookie, token) are always redacted by default, regardless of
other configuration.

(Note: This PR was mostly generated with Claude.)

---

Breaking Changes

None. The new networkRecording option on ReactNativeOptions is optional and defaults to {}
(feature off). Existing SDK behavior is unchanged.

---

New APIs

The following are added to the public API surface of @launchdarkly/observability-react-native:

NetworkRecordingOptions (new exported type):

type NetworkRecordingOptions = {
  recordHeadersAndBody?: boolean      // master gate; default false
  networkHeadersToRedact?: string[]   // headers to redact (case-insensitive)
  headerKeysToRecord?: string[]       // header whitelist (overrides redact)
  networkBodyKeysToRedact?: string[]  // JSON body keys to redact
  bodyKeysToRecord?: string[]         // JSON body key whitelist (overrides redact)
}

ReactNativeOptions.networkRecording (new optional field):

networkRecording?: NetworkRecordingOptions

This is a minor version bump (new opt-in API, no breaking changes).

Note: urlBlocklist placement

In the web SDK (highlight-run), urlBlocklist lives inside NetworkRecordingOptions. In the
React Native SDK it is intentionally omitted from NetworkRecordingOptions because it already
exists as a top-level field on ReactNativeOptions (where it controls OTel trace header
propagation). The existing top-level urlBlocklist is reused to also gate header/body recording,
so there is no duplication.

---

Files Copied From highlight-run

• src/listeners/network-listener/utils/models.ts — copied from
  sdk/highlight-run/src/client/listeners/network-listener/utils/models.ts with no changes

• src/listeners/network-listener/utils/network-sanitizer.ts — copied from
  sdk/highlight-run/src/client/listeners/network-listener/utils/network-sanitizer.ts with no
  changes

• src/listeners/network-listener/utils/xhr-listener.ts — copied from
  sdk/highlight-run/src/client/listeners/network-listener/utils/xhr-listener.ts, stripped to
  getBodyThatShouldBeRecorded and its size-limit constants only; removed XHRListener,
  getBodyData, the json-stringify-safe import, and all other browser-patching code

New file (no direct equivalent in highlight-run):

• src/listeners/network-listener/network-listener.ts — exports FetchHook and XHRHook,
  curried functions that take NetworkRecordingOptions and return the appropriate
  applyCustomAttributesOnSpan handlers for OTel's FetchInstrumentation and
  XMLHttpRequestInstrumentation

---

Testing

The existing source files copied from highlight-run have no unit tests in that package, so adding unit tests is deferred to a follow-up PR, if desired. The natural candidates would be:

• network-sanitizer.test.ts — sanitizeHeaders and sanitizeUrl (pure functions)
• xhr-listener.test.ts — getBodyThatShouldBeRecorded (pure function)
• network-listener.test.ts — FetchHook/XHRHook with a mocked Span

---

Note

Medium Risk
Adds optional recording of HTTP headers/bodies onto OTel spans; despite redaction controls, mistakes or misconfiguration could capture sensitive data and increase span size/perf overhead.

Overview
Adds a new networkRecording option (via exported NetworkRecordingOptions) to optionally attach sanitized request/response headers and bodies to OpenTelemetry FetchInstrumentation/XMLHttpRequestInstrumentation spans.

Introduces a network listener + sanitizer utilities that always sanitize span URL attributes (redacting credentials and sensitive query params), redact known sensitive headers, support header/body allowlists/redaction lists, and applies a built-in DEFAULT_URL_BLOCKLIST (merged into urlBlocklist) to prevent recording for specific auth/token endpoints.

^{Reviewed by Cursor Bugbot for commit 45db54b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 45db54b. Configure here.}

[Vadman97]

looks fine to me as is to keep the urlBlocklist on the existing options rather than tthe network recording options