Add native Datadog Flags Flutter client

[leoromanovsky]

Motivation

Flutter customers need a Dart-native Datadog Flags client that matches the mobile precompute model without bridging through iOS or Android SDKs. The SDK also needs a dogfood path that proves the example app is making real precompute, exposure, and flagevaluation EVP intake requests.

Changes

This PR adds a new datadog_flags Flutter package that fetches precomputed assignments, resolves typed values and details synchronously after context load, persists last-known assignments, reports RUM feature flag evaluations, sends deduped exposure events to EVP intake when doLog is true, and aggregates flagevaluation metrics for EVP intake. It also stores the initialized Datadog SDK configuration so the flags package can derive the default Datadog context from the existing SDK.

The simple example app now includes a live Flags dogfood screen that can run against Datadog endpoints with dart-defines for DD_SITE, DD_ENV, DD_CLIENT_TOKEN, DD_APPLICATION_ID, targeting context, and flag key lists. By default, it evaluates the boolean, string, integer, float, and JSON dogfooding flags. The screen renders each resolved value under its flag key so long keys and JSON values have room, and it keeps only the counters that are useful while dogfooding the app: evaluations recorded and exposures. The counters wrap a real forwarding HTTP client; they observe outgoing requests before forwarding them to the live precompute and EVP intake endpoints.

The package tests include mirrored precomputed fixtures from DataDog/ffe-system-test-data#12 until that fixture PR can be consumed directly.

Decisions

The implementation is native Dart and intentionally does not depend on or bridge to native flag SDKs. It follows the precompute API shape accepted by the live CDN endpoint: /precompute-assignments.

Gov sites fall back to US1, and future OpenFeature work stays separate from this MVP. Dogfood validation uses real Datadog requests. The forwarding counter only observes requests at the HTTP boundary and forwards them, which keeps it useful for the example app without creating a local backend that could obscure request shape, auth issues, exposure logging, or flagevaluation EVP tracks.

Validation

• iOS simulator dogfood launch with DD_SITE=datad0g.com, DD_ENV=staging, and the default dogfooding flag set: assignments ready, evaluations recorded = 5, exposures = 1; boolean = false, string = variant_2, integer = -5, float = 1.0, JSON = { "ai_model": "openai", "enabled": true }. All five flags fit on the first screen with values under keys.
• Android emulator dogfood launch with DD_SITE=datad0g.com, DD_ENV=staging, and FLAGS_STRING_KEYS=ffe-dogfooding-string-flag: assignments ready, evaluations recorded = 1, exposures = 1, string flag value = variant_2.
• Unit tests assert that exposures are posted to https://browser-intake-datadoghq.com/api/v2/exposures?ddsource=flutter with EVP headers and that flagevaluation metrics are posted to https://browser-intake-datadoghq.com/api/v2/flagevaluation?ddsource=flutter with EVP headers.

Question for developers

• Do you want this PR split into several smaller pieces? I can do core library, public API, example app as 3 stacked if desired.