fix: Report data source Valid status before signaling readiness

[kinyoklion]

Summary

Fixes a flaky test failure (TestDefaultDataSourceIsStreaming, seen on CI as status INITIALIZING instead of VALID right after a successful client start) caused by an ordering race between the readiness signal and the data source status update.

In the FDv1 streaming data source, a successful initial put closed the closeWhenReady channel before updating the data source status to Valid. A caller blocked in MakeCustomClient can wake on the channel close and read the status while it still says Initializing. The FDv2 synchronizer path had the same ordering (channel close before UpdateStatus). The FDv1 polling data source already does this in the correct order (status first, then readiness), so this change brings the other two paths in line with it.

For the streaming source, the Valid status update stays in its single existing location after the event handling; the put branch now records that initialization occurred, and the readiness notification runs after that shared status update. setInitializedAndNotifyClient is idempotent (atomic initialized flag plus sync.Once for the channel close), so the deferred notification is safe.

The race window is a few instructions wide, so it only fires on loaded runners. Verified by widening the window with a temporary sleep: the test fails deterministically with the exact CI failure signature under the old ordering, and passes 50/50 with the new ordering even with a sleep inserted between the status update and the readiness notification.

Also adds an immediate post-start status assertion to TestFDV2StreamingSynchronizer so the FDv2 ordering is regression-tested the same way TestDefaultDataSourceIsStreaming covers FDv1.

---

Note

Overview
Fixes a race where readiness (closeWhenReady) could fire before the data source reported Valid, so callers waking on client start could still see INITIALIZING (flaky TestDefaultDataSourceIsStreaming on CI).

In FDv1 streaming, a successful initial put no longer closes the readiness channel inside the init branch; it defers setInitializedAndNotifyClient until after the shared UpdateStatus(Valid) path runs for the event. FDv2 fdv2_datasystem now calls UpdateStatus before readyOnce closes closeWhenReady, matching the polling data source’s status-first ordering.

FDv2 e2e (TestFDV2StreamingSynchronizer) asserts Valid status immediately after MakeCustomClient returns instead of blocking on WaitFor, so FDv2 ordering is regression-tested like the FDv1 streaming test.

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