[Bug] Handle server-initiated WebSocket closes without reconnecting

[GregHolmes]

Summary

A server-initiated WebSocket close does not reliably notify onDisconnected, and non-1000 closes are treated as reconnectable. Flux STT closes after CloseStream with no status (observed as 1005), so applications that wait for the server close can hang or reconnect instead of terminating.

Affected version

0.10.0

Evidence

src/main/java/com/deepgram/core/ReconnectingWebSocketListener.java implements onClosed(...) but not onClosing(...); it calls scheduleReconnect() for every code other than 1000. The class is Fern-generated but temporarily frozen for existing reconnect fixes.

Expected behavior

A server close should result in one onDisconnected callback and should not reconnect when the protocol session has ended.

Acceptance criteria

• Server-initiated close reaches the public onDisconnected handler without an explicit client disconnect().
• A no-status/1005 close after Flux CloseStream does not reconnect.
• Reconnect behavior remains available for actual transport failures.
• Add a MockWebServer regression test.
• Preserve the .fernignore freeze and report the generator gap upstream.

[GregHolmes]

Validated against production on 2026-09-14. Flux invokes onClosing with code 1005 after CloseStream. Echoing that reserved code causes OkHttp to throw IllegalArgumentException, which routes to failure/reconnect. The proposed fix acknowledges 1005 with a valid 1000 close; the live probe then received one onDisconnected callback (code=1005) and observed no reconnect.

[GregHolmes]

The fix now lives in #110, which supersedes the closed #105. #110 retains the Listen V2 CloseStream/no-status-close handling and will close this issue when it merges.