feat(flags): evaluate dynamic offline rules (FFL-2837 PR2)

[btthomas]

Pull request stack

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

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

Summary

This PR adds dynamic and mixed offline evaluation to FlagsClient.

• It stores precomputed and rules branches independently.
• It keeps a valid branch when its sibling is invalid.
• It accepts each context when valid rules are available.
• It preserves a missing targeting key.
• It selects the evaluation path for each resolution.
• It uses matching precomputed data first.
• It uses valid rules data second.
• It maps rules results to FlagDetails.
• It converts real assignments to an internal TrackableAssignment.
• It keeps online and precomputed behavior unchanged.

Reason

A mixed configuration can contain precomputed assignments for one context and rules for other contexts. FlagsClient must select the path when it resolves each flag. This check prevents the SDK from using a mismatched precomputed assignment.

Result behavior

• A flag that the upstream parser removes returns FLAG_NOT_FOUND.
• A missing targeting key stays missing. An empty targeting key is a real value.
• Integer and numeric rules variations both use the OpenFeature type number.
• The fake engine stays as the permanent boundary for path-selection tests.

Tracking

A real rules assignment uses the existing native assignment bridge. The bridge reports the assignment through the same Datadog path as online and precomputed assignments.

• The SDK calls the bridge for each real assignment.
• A false doLog value does not stop the bridge call.
• Native code applies doLog to the exposure event.
• The SDK supplies an empty extraLogging object because the current Android bridge requires it.
• The current mobile bridge does not accept the split serial ID or evaluator timestamp.

Error, disabled, unmatched default, no-variant default, type-mismatch, and missing-flag results are not tracked.

Temporary upstream code

This PR adds one TODO(FFL-2837) marker. It keeps the temporary rulesBased compatibility shape until a published flagging-core release contains FlagsConfiguration.rules.response from openfeature-js-client#344.

PR1 contains the other upstream compatibility markers. The targeting-key policy and the deterministic fake are not temporary.

User impact

The existing offline client can evaluate rules after a context change. It does not fetch data. Matching precomputed data still has priority.

The provider does not pass its effective resolution context in this PR. PR3 adds that connection and the customer documentation.

Checks

• yarn tsc --noEmit -p packages/core/tsconfig.json
• Targeted ESLint for the changed TypeScript files
• 103 flags tests

[sameerank]

According to the PR description

A flag that the upstream parser removes returns FLAG_NOT_FOUND

Once we consume the parser from DataDog/openfeature-js-client#344, malformed known flags should be preserved in precomputed.flagErrors and resolve to the coded default with PARSE_ERROR, matching core/browser. I see this PR already handles flagErrors before this fallback. Can you update the description and add an integration test using the upstream parser output?

[sameerank]

I think this should include PARSE_ERROR and should map to OpenFeature’s ParseError. Reserve GENERAL for failures that are more unexpected and harder to classify