fix: Reconnect the FDv2 stream after a restart that follows an earlier disconnect

[kinyoklion]

Summary

The FDv2 streaming synchronizer restarts its stream with interrupt() after a goodbye, invalid data, or a protocol error. If the stream had disconnected at any earlier time, okhttp-eventsource reports that interrupt() as a StreamClosedByCallerException fault. handleError treated every such fault as a shutdown, so the synchronizer thread exited. The stream did not reconnect, and the data system got no further results.

Now handleError stops only when close() was called. After a restart it continues to read, and the event source reconnects. The restart already queued its result and recorded the stream init, so the fault does not add either one again.

New tests in StreamingSynchronizerImplTest cover a goodbye and invalid data after an earlier disconnect. They also cover close() after an earlier disconnect, both during a restart and without one.

---

Note

Overview
Fixes FDv2 streaming stopping permanently when a deliberate restartStream() (goodbye, invalid data, etc.) follows an earlier disconnect. OkHttp EventSource surfaces interrupt() as StreamClosedByCallerException, and handleError used to treat every such fault as shutdown and exit the read loop.

handleError now stops the stream only when close() set closed under closeLock. After a restart-induced caller close it returns true so the thread keeps consuming events and reconnects, without duplicating queued results or stream-init diagnostics already handled by restartStream(). Real failures still call recordStreamInit(true) on the non–caller-close path.

Adds integration tests for goodbye and invalid data after a prior disconnect, plus close() during/after reconnect so no extra HTTP connections are made.

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