chore: Add support for FDv2 fallback and recovery.

[kinyoklion]

Adds support for FDv2 fallback and recovery.

This doesn't add support for fallback to FDv1.
It also does not finish data source status support.

It does some refactoring to limit the complexity of the FDv2DataSource by moving some implementation details regarding synchronizer state handling and conditions out of its implementation.

---

Note

Implements FDv2 fallback/recovery and refactors synchronizer orchestration.

• Adds FDv2DataSourceConditions with timed FallbackCondition (on prolonged INTERRUPTED) and RecoveryCondition (time-based), and wires them into FDv2DataSource run loop
• Extracts synchronizer lifecycle into SynchronizerStateManager and SynchronizerFactoryWithState for active-source tracking, rotation, and blocking on terminal errors
• FDv2DataSource now supports configurable timeouts (defaults: fallback 2m, recovery 5m), applies thread priority, logs via injected LDLogger, and returns FDv1 fallback signal (execution still TODO)
• FDv2DataSystem constructs FDv2DataSource with threadPriority, DataSource sub-logger, and shared executor; logging refined for polling/streaming components via new names in Loggers
• Extensive unit tests added for conditions, data source behavior (fallback/recovery/closure), and synchronizer state manager

^{Written by Cursor Bugbot for commit e6b032e. This will update automatically on new commits. Configure here.}

[kinyoklion]

We may need to discuss the spec. My interpretation is that the synchronizer just needs to run for the recovery time, not that it needs to be in any specific state.

Considering the fallback time is less than the recovery time, if the data source is in a bad state it will fallback before recovering.

The question is if we care about recovering near having received a changeset. Or if we want changesets to reset the time.

[kinyoklion]

A condition completes when the conditions requirements are met. It is informed by being fed the data source changes. If doesn't wrap the data sources themselves, because that increases complexity of handling the asynchronous nature, and doesn't clearly separate the responsibility.

A condition could complete inside an inform callback, in which case the state change will be caught in the next loop pass.

[kinyoklion]

This is just a move to a new file.

[kinyoklion]

bugbot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}