ObsClient stays in ConnectionState.Connected after silent WebSocket disconnect

[Kenshin9977]

Library version: 3.0.0 / 3.0.1
Target framework: net8.0 (ObsClient), running under net10.0
OBS Studio: 30.x with obs-websocket v5

Symptom

After a successful request (in our case SetInputSettings with overlay: true), the WebSocket session disappears from OBS's Tools → WebSocket Server Settings → Connected Sessions list. The ObsClient instance, however, continues to report ConnectionState == Connected:

• No PropertyChanged event fires for ConnectionState.
• AutoReconnect = true does not trigger a reconnect.
• Subsequent requests on the same ObsClient silently fail (no exception is thrown; the request just doesn't reach OBS).
• Restarting our app restores everything; restarting just OBS while keeping our process alive does not, because the client never sees the disconnect.

Reproduction (minimal)

1. Connect with autoReconnect: true, EventSubscriptions.None.
2. Wait for ConnectionState == Connected.
3. Send a SetInputSettings request that targets a Browser Source's url.
4. Look at OBS's connected-sessions panel — the session is gone within a second.
5. Send another SetInputSettings request a few seconds later: no exception, no effect, OBS doesn't see it.
6. client.ConnectionState still returns Connected throughout.

What we ended up doing

We refactored to a connect-per-push pattern (new ObsClient for each request, Disconnect()+Dispose() after the response). It sidesteps the issue but means we can't rely on the persistent connection model the library encourages.

Repo where this is actively used: https://github.com/Kenshin9977/Discord-Overlay (issue #6 tracks the user-visible symptom, fixed in v2.0.1 via the workaround).

Likely root cause area

The state machine doesn't observe a WebSocket.State != Open transition between requests, so neither PropertyChanged nor AutoReconnect fires. We didn't dig into the source past confirming the symptom — happy to provide more diagnostics if useful.