fix(logging): stop reporting failed /v1/log sends as error beacons (feedback loop)

[darrenli-rokt]

Summary

LoggingService.log() reports a failed /v1/log POST as an error to /v1/errors. When /v1/log is rate-limited, the 429 surfaces to fetch as a TypeError: Failed to fetch, so each dropped log emits an error beacon that is itself rate-limited — a self-amplifying feedback loop at the log frequency.

This path is reachable on any page once logging is enabled via config (#98) and now that the ROKT_DOMAIN gate has been removed (#99): a rate-limited client turns dropped /v1/log beacons into /v1/errors traffic.

Fix

Make diagnostics-log sends fire-and-forget — do not re-report a failed log send as an error. ReportingTransport already logs the failure to the console; genuine errors continue to flow through ErrorReportingService.

-    this._transport.send(this._loggingUrl, INFO, entry.message, entry.code, undefined,
-      (error) => { this._errorReportingService.report({ message: 'LoggingService: Failed to send log: ' + error.message, ... }); });
+    // fire-and-forget — see comment in code
+    this._transport.send(this._loggingUrl, WSDKErrorSeverity.INFO, entry.message, entry.code);

Test

• Updated the LoggingService fetch-error test to assert no error beacon is emitted on send failure (fire-and-forget).
• npm run lint clean · npm test 205/205 pass · npm run build OK.
• dist/ intentionally not committed (regenerated by release automation).

Draft — note for reviewers

This addresses the rate-limit→error feedback loop. The same fire-and-forget / Failed to fetch suppression likely applies to the identity and timings beacon-send paths. Separately, genuine identity-resolution errors (IDENTITY_REQUEST / IDENTITY_MISMATCH) are a distinct issue to track on their own.