feat!: DISABLED is a successful evaluation (still defaults)

[jonathannorris]

• Disabled flags now resolve successfully with reason=DISABLED instead of errorCode=FLAG_NOT_FOUND. See the ADR.
• Breaking, but barely: resolved values are unchanged (the caller-provided default is still surfaced).
• The break is only observable for consumers that inspect reason / errorCode on disabled-flag evaluations.

Related Issues

Closes #653
Part of open-feature/flagd#1965

---

Warning

This PR depends on #673 (RPC flagd-selector header wiring) merging first; the cross-flagset disabled scenario in the RPC e2e suite will fail until that lands. All other RPC e2e + in-process scenarios pass.

[gemini-code-assist]

Code Review

This pull request modifies the JsonEvaluator in the flagd provider to return a ResolutionDetails object with a Reason.Disabled status instead of throwing a FeatureProviderException when a flag is disabled. The corresponding unit tests have been updated to verify that evaluating a disabled flag returns the correct default value, a disabled reason, and a null variant, even when targeting rules are present. There are no review comments to address.

[jonathannorris]

Note on why we return defaultValue rather than null for disabled flags, tagging @suthar26 and @toddbaert since this touches the ADR intent.

The Java provider (open-feature/java-sdk-contrib#1800) returns null for the value field, and the Java SDK substitutes the caller's code default when it sees null. That's the cleanest implementation of the ADR's "omit value, SDK uses code default" intent.

We can't do the same in .NET. The provider interface uses non-nullable value types:

Task<ResolutionDetails<bool>> ResolveBooleanValueAsync(string key, bool defaultValue, ...)
//                                                                  ^^^^ can't be null

bool, int, and double are value types; they always have a value. There's no Optional<bool> in the contract. The .NET SDK also doesn't have fallback logic for this case: defaultValue is only substituted on exception, not on a successful resolution with default(T). If we returned default(bool) (false) and the caller passed true as their default, they'd get false back.

Go has the same constraint (GenericResolutionDetail[bool]) and Go providers handle it the same way, returning defaultValue when the flag is disabled.

The correct fix would be adding substitution logic to the .NET SDK itself (when reason=DISABLED, use defaultValue), but that's a separate change. Until then, returning defaultValue from the provider achieves the same end result for the caller.