feat(openfeature): include RUM user in evaluation context

[btthomas]

Summary

Use the current RUM user as default OpenFeature evaluation context for the online Datadog provider, matching the browser SDK behavior from DataDog/openfeature-js-client#354.

• map the RUM user ID to targetingKey
• map name, email, and flat primitive extraInfo values to evaluation attributes
• let explicitly supplied OpenFeature fields win, including an explicitly empty targeting key
• use the same enriched context for assignment fetching and evaluation tracking
• refresh from the latest RUM user when the OpenFeature context is reconciled
• keep compatibility with older compatible core package versions
• honor rumIntegrationEnabled: false

This is implemented entirely in the JavaScript/TypeScript packages; no Android or iOS SDK changes are needed.

Acceptance plan

• A RUM user supplies a missing OpenFeature targeting key and supported attributes.
• Explicit OpenFeature values take precedence over RUM values.
• Nested, array, null, and unsupported RUM attributes are excluded.
• Disabling RUM integration disables context enrichment.
• Fetching and evaluation tracking receive the same enriched context.
• Reconciliation reads the latest RUM user.
• Offline-provider context semantics remain unchanged.

Validation

• yarn exec jest --watchman=false --runInBand --projects packages/core packages/react-native-openfeature
  • 55 suites passed, 1 skipped
  • 792 tests passed, 1 skipped
  • 7 snapshots passed
• TypeScript checks passed for both affected packages.
• Targeted ESLint and Prettier checks passed.
• git diff --check passed.

OfflineProvider follow-up

After completing this code pass, I reviewed the in-progress dynamic OfflineProvider stack: #1346, #1347, #1348, plus the context-semantics work in #1359.

Recommended follow-up after that stack lands:

1. Rebase this integration with the dynamic-rules stack and keep precomputed snapshot matching against the original explicit context.
2. Enrich only the context passed to the rules evaluator when evaluation falls through to the dynamic rules branch.
3. Preserve explicit OpenFeature precedence and the rumIntegrationEnabled opt-out.
4. Reuse that enriched rules context for native exposure/evaluation tracking.
5. Add multi-user tests that switch the RUM user between evaluations, plus mixed precomputed/rules tests proving precomputed behavior remains unchanged.
6. Update the OfflineProvider docs to distinguish dynamic-rule RUM defaults from exact precomputed snapshot context.

This avoids changing current offline/precomputed semantics while enabling server-SDK-style multi-user local rules evaluation in the follow-up.