feat(openfeature): expose dynamic offline rules (FFL-2837 PR3)

[btthomas]

Pull request stack

1. Plan PR (#1345)
2. PR1: Rules engine boundary (#1346)
3. PR2: Dynamic offline evaluation (#1347)
4. PR3: Provider API and documentation (feat(openfeature): expose dynamic offline rules (FFL-2837 PR3) #1348) <- you are here

This description uses Simplified Technical English. Technical names and API names do not change.

Summary

This PR exposes dynamic offline rules through the existing offline provider.

• The offline provider passes the effective OpenFeature context and logger to FlagsClient.
• The online provider keeps its current cache path.
• An empty OpenFeature context lets FlagsClient use its stored context.
• A missing targeting key stays missing. The SDK does not replace it with an empty string.
• Rules configurations stay ready after context changes.
• Context changes do not fetch configurations.
• Integration tests cover two subjects, two results, and TARGETING_KEY_MISSING.
• The README explains precomputed, rules, and mixed configurations.
• The README warns that untrusted regular expressions can block the JavaScript thread.
• Both example applications include a rules-context switch.

Reason

The provider lifecycle already supports offline configuration and context changes. The provider only needs to pass the current resolution context to the core rules path. A new provider class is not required.

When OpenFeature supplies no effective context, the provider passes undefined to the internal resolution method. This preserves an embedded precomputed context. The provider still passes the OpenFeature logger.

OpenFeature hook constraint

Web SDK 1.8 freezes the hook context before it calls before hooks. It does not accept a replacement context from a hook. This PR does not claim that a hook can replace one resolution context.

Temporary upstream code

This PR adds three fixture TODO(FFL-2837) markers:

• One in the standard example
• One in the new-architecture example
• One in the real-provider integration test

The complete stacked branch contains 12 markers. PR1 and PR2 contain the other nine markers.

The three PR3 fixtures use the legacy rulesBased JSON wire. Replace them with one canonical version 1 rules.response base64 fixture after a published flagging-core release contains openfeature-js-client#344. Reuse that fixture for the Metro, Hermes, and JSC checks.

Tracking metadata is not an upstream blocker. Rules assignments use the existing native bridge.

User impact

A customer can load one rules configuration and call OpenFeature.setContext for new subjects. The provider evaluates each context locally. It does not fetch assignments.

Precomputed-only behavior does not change. Matching precomputed data has priority when both branches exist.

Keep the original wire when it contains rules. configurationToString cannot recreate the protobuf rules payload.

Remaining gates

• Publish and pin the flagging-core release that contains PR Add Support for RN 0.71 #344.
• Replace the three legacy fixture branches.
• Define the regular-expression, salt, size, and security policies.
• Run the packed dependency and rules flow in Hermes and JSC.

This PR remains a draft until these gates are complete.

Checks

• yarn tsc --noEmit -p packages/core/tsconfig.json
• yarn tsc --noEmit -p packages/react-native-openfeature/tsconfig.json
• yarn tsc --noEmit -p example-new-architecture/tsconfig.json
• Targeted ESLint for the provider and core files
• 34 OpenFeature tests
• 103 core flags tests
• Formatting and git diff --check