Implements the OpenFeature tracking API (spec §6) in the provider, matching the behavior of the Java, .NET, and Node providers.

• client.track(...) previously no-opped silently: the OpenFeature Python SDK only forwards tracking to providers that implement track (spec 6.1.4), so custom/experimentation events were being dropped with no error.
• TrackingEventDetails.attributes map to the LD event data, and TrackingEventDetails.value maps to metric_value.
• A track call without an evaluation context logs at info level and sends nothing, since LaunchDarkly requires a context to attribute the event to.

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; found while auditing the LaunchDarkly OpenFeature providers for missing spec features.

Describe the solution you've provided

LaunchDarklyProvider.track converts the OpenFeature evaluation context to an ldclient.Context with the existing EvaluationContextConverter and then calls the narrowest LDClient.track overload that fits the details supplied: name only, name + data, or name + data + metric value.

Describe alternatives you've considered

Sending an event with an empty/invalid context when no context is supplied, which would produce events LaunchDarkly cannot attribute. The Java provider already logs and skips in this case, so this follows that precedent.

Additional context

TrackingEventDetails.attributes defaults to {} rather than None, so an empty attribute map is normalized to None to avoid sending an empty data object. Tests patch LDClient.track and assert the exact argument shape for each of the four combinations (no context, no details, attributes only, value + attributes, value only).

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