docs: Explain that the SDK keeps retrying after identify or start reports a failure

[jsonbailey]

Summary

Stacked on #351. The FDv1 streaming data source no longer stops for good after an HTTP error such as a 401.

• The SDK owns the reconnect delay. It makes the SSE client with autoReconnect: false, closes it on any failure, and reconnects after the RetryState delay: 1 second up to 30 seconds normally, and 5 minutes up to 1 hour after an unexpected failure. The backoff resets after 60 seconds of healthy streaming.
• Logs use warn for normal failures and error for unexpected ones, state the real delay, and add a credential hint only for 401 and 403.
• A restart for a connection that has already been replaced is ignored, so a late invalid message cannot close a newer, healthy connection.
• FDv2 streaming maps the new SSE errors to interrupted, as Android FDv2 does, and logs the failure kind.
• A cached identify no longer reports an unhandled error when the first stream attempt fails.
• Contract test service: declares retry-conformance-fdv1-streaming.
• common_client needs the released launchdarkly_event_source_client and launchdarkly_dart_common versions before this merges. The pin bumps follow those releases.

[jsonbailey]

Cross-SDK note, for team discussion: on a data source failure, Android completes identify as a success without setting initialized (ConnectivityManager start callback onError) and keeps retrying. iOS waits for data, and identifies queued behind a waiting one stay blocked. Flutter keeps main's result (IdentifyError / start() false) and now keeps retrying in the background. We tried "wait for data" here, but it caused several races in the identify queue, so we chose the Android model.

[jsonbailey]

Lets make sure client SDKs are willing to terminate a not yet finished identify / data fetch if another identify comes in, this behavior may be made worse by RETRY conformance.