[OFREP] Should the provider handle codeDefaultFlag responses? Disabled flags surface FLAG_NOT_FOUND

Asking rather than reporting, because I may be misreading either the schema or the intent — and if the answer is "deliberate, for now", that is a useful thing to have written down.

What I observed

disabled-boolean-flag from flagd-testbed:v3.8.0, over OFREP:

$ curl -s -X POST localhost:8016/ofrep/v1/evaluate/flags/disabled-boolean-flag -d '{"context":{}}'
{"key":"disabled-boolean-flag","reason":"DISABLED","metadata":{}}     HTTP 200

The application receives the code default value with errorCode = FLAG_NOT_FOUND.

Why I think it might be unintended

evaluationSuccess in open-feature/protocol's service/openapi.yaml requires only key and reason. value is not required, because one member of its oneOf is codeDefaultFlag:

Note: This schema has no value property. The provider must use the code default value when processing this response.

DISABLED is in that schema's reason enum, so the response above looks well-formed to me: a successful evaluation that defers to the code default.

In Resolver.java (~174-181), handleResolved appears to take its responseValue == null branch and return the code default with FLAG_NOT_FOUND, discarding the reason parsed a few lines earlier. If that reading is right, the effect is not limited to disabled flags — any codeDefaultFlag response would reach the application as a failure error code on an evaluation that succeeded.

Questions

1. Is codeDefaultFlag support intended for this provider, or knowingly out of scope for now? code default flag support landed in the protocol in protocol#49 (2025-08-21) as a breaking change, and I could not find any issue in the org tracking provider-side adoption of it — so "nobody has got to it yet" seems at least as likely as "this is a bug".
2. If it is in scope: is FLAG_NOT_FOUND deliberate here? I would have expected no error code at all, with the reason from the response passed through.
3. Is there a reading of the schema under which the current behaviour is correct and I have this backwards?

How I ran into it

Building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated @disabled-flags capability asserts that a flag disabled in the management system resolves to the code default. Four scenarios fail here, all on the error-code assertion — the value assertion passes, because the provider does fall back to the default on error, so the value looks right while the error code says the evaluation failed.

For calibration, the same scenarios pass against the Go and JavaScript OFREP providers, which is what made me think this is worth asking about rather than a limitation of OFREP itself. I am not attached to any particular answer here.

Start with Resolver.java around lines 174-181 and compare the response handling with the evaluationSuccess and codeDefaultFlag rules in service/openapi.yaml. Run the disabled-flag scenarios from the proposed cross-language provider conformance suite, then verify whether codeDefaultFlag responses preserve their reason and avoid reporting FLAG_NOT_FOUND.