…#358)

<!-- CURSOR_SUMMARY -->
> [!NOTE]
> Introduces FDv2 data system configuration and robust synchronizer
lifecycle (start/stop), integrates SSE streaming with payload filter,
implements an in-memory feature store, and updates tests and contract
client accordingly.
> 
> - **FDv2/Data System**:
> - Add `Synchronizer.stop()` to interface and implement stop/lifecycle
management in `StreamingDataSource` and `PollingDataSource`.
> - Enhance `FDv2` to track/stop the active synchronizer safely with
locks; ensure threads shut down cleanly.
> - Add `datasystem.config` builders (`polling_ds_builder`,
`streaming_ds_builder`), expose `fdv1_fallback_synchronizer` in config.
> - **Streaming**:
> - Switch to `ld_eventsource.SSEClient`; include payload filter in
stream URI.
> - Handle stream errors by interrupting/closing SSE; stop on
unrecoverable errors; ensure closure on exit.
> - **Polling**:
>   - Add stoppable sync loop with `_stop` flag and `stop()` method.
> - **Store**:
> - Implement thread-safe `InMemoryFeatureStore` with basic CRUD, init,
and diagnostics; integrate with `Store`.
> - **Contract tests**:
> - Support FDv2 `dataSystem` config (initializers/synchronizers,
payloadFilter) in `client_entity.py`.
> - **Tests**:
> - Update streaming synchronizer tests for new SSE client usage and
stop/interrupt behavior.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
e87daa0. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

In the previous setup, we would only check the fallback or recovery
conditions once the synchronizer returned an update. If the synchronizer
was stuck, or nothing was changing in the environment, we would never
check the conditions.

This configuration also exposed an interesting behavior. If the
synchronizer cannot connect, it will emit error updates. Each time we
receive an error, we check if we have failed to initialize for the last
10 seconds. If so, we re-create the primary synchronizer.

When it continues to fail, the first update will trigger the condition
check. And since it has still failed for 10 seconds, it will immediately
error out. With this change, we can be assured a synchronizer is given
at least 10 seconds to try before the condition is evaluated.

…ations (#374)

🤖 I have created a release *beep* *boop*
---


##
[9.13.0](9.12.3...9.13.0)
(2025-11-19)


### Features

* **experimental:** Release EAP support for FDv2 data system
([#376](#376))
([0e7c32b](0e7c32b))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).