[kinyoklion]

Summary

This PR is stacked on #449 so that the flag overrides series applies in order. It does not use that PR's code.

Flag overrides, as defined by the OVERRIDE specification, need three pieces below the store: a marker on the flag and segment model that says a definition came from the override store, evaluator marking that follows every definition an evaluation reads, and an indicator on the evaluation reason that reports the marking to callers. This change adds those three pieces. Nothing sets the marker yet, so the SDK behaves exactly as before. The override store, the overlay, and the data system wiring follow in the next PR.

The model classes FeatureFlag and Segment carry the marker as an attribute that is never serialized, because as_json returns the flag data hash. as_override returns a marked shallow copy and leaves the original unchanged. Only the SDK components that manage override entries will set it.

The evaluator marks an evaluation as override-affected when the evaluated flag, a prerequisite flag at any depth, or a segment read during clause matching carries the marker. A segment counts when it is read, so a segment that does not match, or one read through a negated clause, still marks the evaluation. The marking propagates upward only. A prerequisite's own record reflects the definitions its own subtree read, so a plain prerequisite inside a marked evaluation is recorded as usual, and a prerequisite of an overridden flag is not marked by its parent. An error result is marked when a marked definition was read before the failure, including a failure raised while a prerequisite was being evaluated. An evaluation that reads no marked definition keeps the shared precomputed detail instances.

EvaluationReason#override_affected carries the indicator, following the inExperiment and bigSegmentsStatus precedents. It is written to JSON as overrideAffected only when true, so the wire format of ordinary evaluations is unchanged. with_override_affected returns the same instance when nothing changes, and with_big_segments_status keeps the indicator.

Verification: specs for the model marker (default, copy, original unchanged, not serialized), the reason indicator (default, JSON when true and when false, [], equality, interaction with the big segments status), and the evaluator marking rules (direct, prerequisite at any depth, upward-only propagation, unaffected prerequisite record, segment read with and without a match, negated clause, nested segment, unresolved definition, prerequisite failure, malformed override, error raised during a prerequisite evaluation, big segments status kept). Full suite and RuboCop are clean. Each new spec was checked against a deliberate defect in the code it covers.

The existing FDv1 and FDv2 file data sources keep their current behavior. This series does not change them; the override feature is additive.

This PR also carries a spec-only fix for the Windows job, which failed or passed depending on the random example order. Ruby 3.1 through 3.3 report file modification times in whole seconds on Windows, so a truncation 20 ms after another one does not look like a new write. The reloader specs that need a rewrite to look new now set the file's modification time themselves, and the watcher spec that replaces a symbolic link waits for the next second first on such a platform. No code under lib/ changes, and the specs came in with #449, so the fix sits at the bottom of the stack.

SDK-3249

_{Opened from termag}

[kinyoklion]

bugbot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit ed8fccf. Configure here.}