feat: Add the override marker and override-affected evaluation marking

[kinyoklion]

Summary

This PR is based on the shared file data branch because it builds on the same feature branch history and should merge after it.

This change adds the model and evaluator work that the flag overrides feature of the OVERRIDE specification builds on. Nothing in the SDK sets the marker yet, so the SDK's behavior is unchanged until the override store lands.

Flag and segment definitions can carry an override marker. The Node SDK stores definitions in their JSON data model form, so the marker lives under a reserved, namespaced key. Only the new overrideMarker module names that key. Other code reads or strips the marker through its functions. The serializer omits the marker at the root of a flag or segment, so it never leaves the process, and leaves nested values untouched. Definitions read from LaunchDarkly or from a store lose the key as they are ingested, so only the override store can set it. Only the SDK's override store will set it, on the entries it holds.

The evaluator marks an evaluation as override-affected when any definition it read carries the marker: the evaluated flag, a prerequisite flag at any depth, or a segment consulted during matching, whether or not the segment matched. The marking propagates upward only. A prerequisite evaluation starts its own marker from its own definition and merges it into its parent's marker when it completes, so the record of a prerequisite reflects only the definitions that its own evaluation read. Error results the evaluator produces are marked too, so a malformed override definition yields the caller's default with a marked error reason. The client's own replacement of a result on a requested-type mismatch keeps the marking in the override layer change that follows, where the marker is first set.

The evaluation reason gains an optional overrideAffected indicator that is set only when true, following the inExperiment precedent. The evaluation result carries the same marking as a scalar so that event generation can key on it without reading the reason. Migration operation events keep the indicator on their evaluation reason when it is true. The OpenFeature provider reports it in flag metadata, following the inExperiment precedent.

The tests mirror the Go evaluation library's marking tests: direct marking for off, fallthrough, rule match, and error results, prerequisite records at depth one and two, an unaffected sibling prerequisite, segments matched, not matched, negated, referenced through another segment, and resolved through big segment membership, unresolvable definitions, and the agreement between the result scalar and the reason indicator.

SDK-3247

---

Note

Overview
Introduces experimental flag override plumbing: flag/segment definitions can carry an internal _sdk_override marker (set only by the future override store), and evaluations expose overrideAffected on the reason and result when any read definition was override-sourced—directly or via prerequisites/segments at any depth.

The evaluator tracks marking per evaluation (including prerequisite records and segment reads, even on non-match/negated clauses), merges it up the prerequisite tree without mutating shared reason singletons, and omits overrideAffected from JSON unless it is true (same pattern as inExperiment). Ingest/serialization strips root _sdk_override from LD payloads and persistent-store round-trips while preserving nested customer data that happens to use the same key name.

OpenFeature flag metadata and migration op event conversion forward overrideAffected when true. Until the override store lands, nothing sets the marker, so runtime behavior for normal LD data should stay the same aside from the new optional fields and strip-on-ingest safety.

^{Reviewed by Cursor Bugbot for commit c97929f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 29603 bytes
Compressed size limit: 30000
Uncompressed size: 142116 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 32662 bytes
Compressed size limit: 34000
Uncompressed size: 117055 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 25437 bytes
Compressed size limit: 44000
Uncompressed size: 165420 bytes