fix(core): RUM auto-instrumentation on apps with a custom JSX runtime

[Fiona2016]

Three fixes for RUM not reporting. They were found together but are independent, and the commits are separated accordingly.

1. A failing instrumentation aborted SDK startup

enableFeatures installed the three auto-instrumentations in sequence with no protection, and _initializeFromDatadogProvider calls it before initializeNativeSDK. An exception while installing the first one skipped the other two and aborted the native initialization, so the app got no RUM data at all — buffered DdRum calls never flushed, because the SDK never came up.

The legacy initialize() path installs the features after the native SDK, so the same exception there left views working while silently dropping all three instrumentations. One cause, two very different symptoms, neither pointing at the instrumentation that failed.

Each feature now installs independently and reports its own failure through InternalLog and telemetry. DatadogProvider also catches the initialization promise it starts during render — nothing awaited it, so a rejection left no trace at all, and none whatsoever in a release build that strips console calls.

2. Actions were never recorded when the app uses a custom JSX runtime

Interaction tracking wrapped React.createElement and react/jsx-runtime's jsx. That is only correct when the app compiles JSX to React's own runtime. An app setting a custom jsxImportSource — anything built on react-native-css-interop — compiles to that library's runtime, which captures React's factories while the bundle is evaluated, long before the SDK starts. Patching react/jsx-runtime afterwards can no longer reach the app's elements, so no onPress was wrapped.

Those modules cannot be required from the SDK: Metro resolves requires statically, so a hard-coded require would break bundling for every app that does not depend on them. The app passes its runtimes in instead:

import * as NativeWindJsxRuntime from 'nativewind/jsx-runtime';

config.jsxRuntimes = [NativeWindJsxRuntime];

Three related defects in the same code path are fixed with it:

• jsxs was never patched. Under the automatic transform an element with one child compiles to jsx and one with several to jsxs, so multi-child elements went uninstrumented even without a custom runtime.
• Factory assignments are guarded. A host can expose them as getter-only properties; the resulting TypeError used to propagate out of startTracking — which is how this met problem 1.
• jsxDEV install/uninstall were asymmetric (written to the production runtime, restored from the dev one), and the telemetry calls in the catch path lacked optional-call syntax, so the error handler could raise a second error.

3. The resource reporting promise was discarded

ResourceReporter#reportResource dropped the promise it started, so any rejection on the way to DdRum.startResource was unhandled and invisible: the resource never appeared, with nothing logged.

Tests

• New: an injected runtime has both jsx and jsxs wrapped and restored; a read-only factory does not stop tracking; the native SDK still initializes when an instrumentation throws.
• Full suite green (880 passed), lint and typecheck clean.
• docs/troubleshooting_no_data.md gains a section for the missing-actions case.

Not yet verified

The device-level check is still outstanding: a release build of an app using a custom jsxImportSource should report views, resources and actions, with a negative control confirming each metric returns to zero when the corresponding fix is reverted.