feat: Add the FDv2 data system and expose it through configuration

[kinyoklion]

What this adds

The piece that ties the FDv2 building blocks together and turns them on: FDv2DataSystem, the manager routing that applies FDv2 payloads, and the configuration that opts in. This completes the FDv2 work in common_client — everything below the public Flutter API.

• FDv2DataSystem composes the data source factories the DataSourceManager consumes. It owns the state that must outlive any single orchestrator: the current selector and the context it belongs to. A fresh orchestrator is built per connection-mode switch and per identify; the selector survives mode switches (initializers are skipped when a selector is already held) but resets when the context changes, since a selector is specific to one context. buildFactories() returns factories for streaming, polling, and background — offline has no data source and is handled by the manager directly. Custom connection modes from config replace the built-in definitions by name.
• DataSourceManager payload routing. The PayloadEvent case — a no-op placeholder in the orchestrator PR — now applies the change set through handlePayload and completes the pending identify, the same way DataEvent does for FDv1.
• Configuration & exposure. DataSystemConfig (providing it, even empty, opts into FDv2); LDCommonConfig.dataSystem; LDCommonClient constructs an FDv2DataSystem and installs its factories when dataSystem is configured, otherwise the FDv1 sources run unchanged; and the new public types are exported.

When dataSystem is absent the FDv1 path is byte-for-byte unchanged, so existing behavior is unaffected.

Testing

• DataSourceManager test: a PayloadEvent is applied through handlePayload, marks the source valid, and completes identify (a dropped/no-op payload would leave identify hanging — this distinguishes the real routing from the placeholder).
• FDv2DataSystem tests: buildFactories exposes streaming/polling/background and not offline; each factory builds a fresh data source per call; a custom connection mode replaces the built-in definition.
• DataSystemConfig default (no custom modes).
• Full common_client suite passes; flutter_client_sdk (the dependent package) analyzes and tests clean against these changes.
• End-to-end behavior of the wired data system is exercised by the FDv2 contract tests, which land with the contract-service changes in a later PR (and pass on the integration branch today).

SDK-2186

---

Note

Medium Risk
Changes core flag acquisition wiring when dataSystem is set and alters identify completion for payload events; default behavior is unchanged when config is omitted, but the new path touches initialization and data-source orchestration.

Overview
Adds an EAP opt-in for FDv2: setting LDCommonConfig.dataSystem (even const DataSystemConfig()) switches startup to FDv2DataSystem factories instead of the existing FDv1 streaming/polling/background wiring; leaving dataSystem null keeps the prior path.

DataSystemConfig exposes ConnectionModeId (streaming/polling/background) and optional connectionModes overrides that replace built-in ModeDefinition pipelines. FDv2DataSystem builds per-mode factories (fresh orchestrator per connection), persists selector across mode switches but resets it on context change, and skips initializers when a selector is already held.

DataSourceManager now routes PayloadEvent through handlePayload and shares _completeIdentify with FDv1 DataEvent handling so identify completes when FDv2 payloads land. Public exports add the new config and mode-definition types.

Tests cover payload→identify completion and FDv2DataSystem factory/override behavior.

^{Reviewed by Cursor Bugbot for commit 6225462. Bugbot is set up for automated code reviews on this repo. Configure here.}