[keelerm84]

A TestDataV2 data source registered for changes when it was created, not
when it started to sync. A change made between those two points was in
the initial data and also waited in the queue. The sync then sent the
queued change after the initial data, so the store went back to an older
version until the later changes arrived.

The sync now registers and takes the initial data in one step, under the
lock that an update holds while it saves a change and copies the list of
instances. Each change then reaches a synchronizer once, and in order.

An initializer only fetches, so it no longer registers. Before this
change, FDv2 never stopped its initializers, and each one stayed
registered and queued every later change.

---

Note

Overview
Fixes TestDataV2 sources registering too early and replaying pre-sync changes after the initial full snapshot, which could briefly restore an older flag version when a client started.

TestDataSourceV2 no longer auto-registers on construct. sync subscribes and builds the initial basis in one step via fetch_result { @test_data.subscribe(self) }, so the queue only gets updates after that snapshot. fetch (initializer path) uses the same fetch_result helper but only make_init_data + get_version, so it does not subscribe and will not keep receiving upsert_flag calls.

TestDataV2#add_instance is replaced by subscribe, which atomically adds the instance, snapshots current flags/segments, and returns the version used for the initial transfer. A private fetch_result centralizes lock/error handling and FetchResult wrapping.

Specs exercise explicit subscribe, assert no stale update after the initial sync, and assert initializers do not receive subsequent upsert_flag traffic.

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