feat: Populate OpenFeature flag metadata from the evaluation reason

[kinyoklion]

The provider discarded everything in the LaunchDarkly evaluation reason that did not fit into the OpenFeature reason string, so OpenFeature users could not tell that an evaluation was part of an experiment; the reason detail is now exposed as OpenFeature flag metadata.

• ProviderEvaluation.flagMetadata now carries variationIndex, inExperiment, ruleIndex, ruleId, prerequisiteKey, and bigSegmentsStatus
• Each entry is only present when it applies to the evaluation, so callers must null-check — inExperiment in particular is absent rather than false for non-experiment evaluations
• Key names match the LaunchDarkly reason field names and the attribute names used by the LaunchDarkly OpenTelemetry hooks
• Documented the keys in the README

@cursor review

Implementation details

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

None; this is one of several gaps found while auditing the LaunchDarkly OpenFeature providers against the OpenFeature specification.

Describe the solution you've provided

EvaluationDetailConverter.getProviderEvaluation builds an ImmutableMetadata from the EvaluationReason. Both entry points (typed values and LDValue results) go through it, so object and array evaluations get metadata too.

variationIndex duplicates the information in variant, but as an integer rather than a stringified index, which is what consumers reading metadata for telemetry want. It is omitted along with variant when the SDK returned the default value.

The OpenFeature telemetry conventions only reserve contextId, flagSetId, and version; none of the three map to a LaunchDarkly concept available on the evaluation detail (contextId would need the canonical context key rather than the reason, and could be added separately). Everything here is therefore LaunchDarkly-specific, named after the reason fields so it lines up with EvaluationReason and with the feature_flag.result.* attributes the LaunchDarkly OTel hook emits.

Describe alternatives you've considered

• A single nested reason structure: ImmutableMetadata only holds scalars, and flat keys are what telemetry hooks read.
• Always emitting inExperiment: false: cheap for consumers, but it makes the metadata claim knowledge about evaluations where the reason carries none.

Additional context

./gradlew test javadoc passes, including new cases per metadata entry and one covering object results. Nothing outside the converter changes. No visual preview applies — this is a server-side provider change.

Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Requested by: @kinyoklion

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[kinyoklion]

We should move these names to defined constants instead of being inline.

[devin-ai-integration]

Done in c93fd2c — the keys are now private static final constants on EvaluationDetailConverter. I'll mirror the same constant treatment in the other providers, and Ryan asked for an sdk-specs spec defining these names, so the spec will be the source of truth for them.