feat: Add the FDv2 data system orchestrator

[beekld]

Summary

Adds the FDv2 orchestrator, the DataSystem implementation that owns the
in-memory store and keeps it populated. It runs an initializer phase to obtain
a basis, then a synchronizer phase for ongoing changes.

The initializer phase tries each initializer in order until one produces a
basis. The synchronizer phase then runs one synchronizer at a time and rotates
between them on three triggers:

• A fallback timer advances to the next synchronizer after a sustained
  interruption.
• A recovery timer returns to the primary synchronizer after the recovery
  interval.
• A terminal error blocks a synchronizer and advances past it.

Initialization is signaled as complete on the first basis and as failed once
every source is exhausted without one, because the client's initialization path
already resolves to success or failure. Synchronizer status transitions are
logged, with interruptions at info (not repeated while ongoing) and terminal
errors at warn.

---

Note

Overview
Adds FDv2DataSystem, the FDv2 DataSystem implementation that owns an in-memory store and keeps it updated via a tokio run loop.

Initializer phase: tries each initializer factory in order until one returns a non-None changeset; applies it with TransactionalDataStore::apply, signals init_complete(true), and tracks the changeset selector for later sync calls.

Synchronizer phase: SourceManager rotates among synchronizer factories—cyclically skipping blocked sources, with fallback after sustained Interrupted (timer), recovery back to the prime when not on primary, and block + advance on TerminalError. Successful changesets update the store and selector; ChangeSetKind::None does not clobber the selector. Shutdown ends the loop without init signaling; if no basis was ever obtained, init_complete(false) runs once.

Wires the module in fdv2/mod.rs and removes stale dead_code allows on ChangeSet.selector and TransactionalDataStore. Includes broad unit/integration-style tests for rotation, timers, init signaling, and selector propagation.

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

[cursor]

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

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f3e5a99. Configure here.}

[keelerm84]

A few questions and suggestions on the orchestrator, mostly around the initializer chain and test coverage.

[keelerm84]

If the first initializer returns a basis, then we wouldn't need to build the subsequent ones. Maybe we should build them as we iterate instead of all at once then?

[keelerm84]

Can this not be simplified down first == self.current_factory_index && first.is_some()?

[keelerm84]

Initializers can arrive with a full change set but no basis (e.g. file based initialization). So applying a change set and determining if the init chain is done are two different things.

[keelerm84]

Might be worth implementing the test data source for FDv2 so future tests can rely on that if needed.

[keelerm84]

Based on my earlier comment, you will also want a test that gets a payload from the first source, doesn't have a basis, and then continues onto the second one.