fix(reporting): don't beacon transport/network-failure error reports

[darrenli-rokt]

Summary

ErrorReportingService.report() beacons every report to /v1/errors. Many reports merely describe a failed network request — most commonly an identity request that failed with Failed to fetch (which is also how a rate-limited 429 surfaces when its response is CORS-blocked or dropped). Beaconing such a report emits another request to /v1/errors that is itself rate-limited/blocked, feeding back into the same per-IP limit — a self-amplifying loop.

Fix

Drop reports whose message matches a browser network-failure phrase (Failed to fetch / Load failed / Firefox's NetworkError when attempting to fetch resource / Network request failed). Genuine application errors (any other message) are still reported.

report(error) {
  if (!error) return;
  if (_isNetworkFailureMessage(error.message)) return; // <-- added
  ...
}

Test

• it.each over the three network-failure phrasings → asserts no beacon is sent.
• A genuine identity error (e.split is not a function) → still beaconed.
• npm run lint clean · npm test 209/209 · npm run build OK.
• dist/ not committed (regenerated by release automation).

Notes for reviewers

• Companion to the LoggingService fire-and-forget fix (separate PR) — together they stop the /v1/log and /v1/errors beacon paths from re-reporting their own rate-limited/blocked sends.
• This path became broadly reachable once logging is enabled via config (fix: use mParticle config logging flag #98) and the ROKT_DOMAIN gate was removed (fix: Remove ROKT_DOMAIN gate from logging #99).
• Filtering is done on the message string here for minimal blast radius; a typed-error approach upstream could be a follow-up.
• Draft pending review + coordination with the companion fix and the logging-flag rollout.