[Bug] Provide explicit lifecycle management for shared OkHttp resources

[GregHolmes]

Summary

After a WebSocket client is disconnected, a short-lived JVM can remain alive for roughly OkHttp's dispatcher idle timeout. Each WebSocket disconnect() shuts down only its reconnect executor; the SDK-owned shared OkHttpClient dispatcher and connection pool remain active. This is especially visible under mvn exec:java after streaming Speak or Listen examples finish.

Affected version

0.10.0

Evidence

The WebSocket clients delegate disconnect() to ReconnectingWebSocketListener.disconnect(), which closes the socket and shuts down the listener executor. ClientOptions owns the shared OkHttpClient, but neither the generated API client nor custom DeepgramClient exposes a documented close/shutdown lifecycle.

Design constraint

Do not shut down the shared OkHttp dispatcher from one resource WebSocket client: callers may continue using the parent SDK client for REST or other sockets.

Acceptance criteria

• Define SDK-client-level ownership and shutdown semantics.
• Expose an explicit, documented way to release SDK-owned OkHttp resources.
• Do not shut down caller-supplied OkHttpClient instances.
• Add an isolated-process regression test or equivalent lifecycle verification.
• Update streaming examples to use the supported client lifecycle.