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

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.
• Empty OpenFeature context still uses the embedded precomputed 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 rules, precomputed data, mixed data, domains, security, and opaque rules wires.
• Both example applications include a rules-context switch.

Reason

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

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 change one resolution context.

Temporary upstream code

This PR has three fixture TODO(FFL-2837) items:

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

These fixtures use the legacy rulesBased JSON wire. Replace them with the canonical protobuf rules wire after a flagging-core release contains openfeature-js-client#344.

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

The stack remains in draft while PR #344 is unpublished and the regular expression, size, and security policies are incomplete.

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 a rules wire because the parsed object does not contain the original protobuf payload.

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
• 33 OpenFeature tests
• 103 core flags tests
• Formatting and git diff --check