fix: Prevent the data source status from changing after the client closes

[jsonbailey]

Summary

After close(), work that started before the close can still finish. For example, a put that is still being stored calls setValid() when it completes. That changed the data source status and the last error on a client that was already closed.

• After the data source manager stops, in-flight data source work does not change the data source status and does not complete a pending identify.
• The guard is in DataSourceManager and DataSourceEventHandler, the code that sends status updates. DataSourceStatusManager is unchanged.
• Tests hold persistence open across stop() for put, FDv2 payload, patch and delete (success and failure), and for a queued status event.

[jsonbailey]

Cross-SDK note: same result as the other SDKs (no status change after close), different place. Android checks closed in its data sources, which works because they apply payloads and set status synchronously. Here the data source only emits events, and this class applies them asynchronously after persistence, so the guard has to be here. iOS has no status manager. A status-value latch (the server SDK approach) does not fit, because close sets no terminal state and the status manager outlives identify and mode changes.