No notification for first connect or for disconnect (only reconnect)

[Yaraslaut]

Summary

QtWebSocketBackend exposes setReconnectHandler, which deliberately fires only on
re-connect — it exists so Bridge can re-register handlers after a drop, and skipping the
initial connect is correct for that purpose.

There is no notification for the first successful connect, and none for a disconnect.

Why it matters

UI that reflects live connection state needs both. A status indicator has to show
"connecting… / connected / offline", and the only currently available signal covers just the
second and later connects:

• First connect — waitForConnected() answers this, but it blocks. On a browser/WASM
  target blocking the event loop hangs the page, so it isn't usable there at all; even on
  desktop it means blocking startup on a network round-trip.
• Disconnect — there is no hook. A client learns the socket dropped only indirectly, when
  a later action fails.

The result is that an application either polls, or duplicates the socket-state tracking morph
is already doing internally.

Suggested fix

Two setters alongside the existing one:

/// Invoked on every successful connect, including the first.
void setConnectHandler(const std::function<void()>& handler);

/// Invoked whenever the socket drops. Fires before reconnect scheduling, so an observer
/// sees the disconnected state even when a retry follows immediately.
void setDisconnectHandler(const std::function<void()>& handler);

Both invoked on the backend's own thread, nullptr to clear — matching
setReconnectHandler's existing contract.

Purely additive: setReconnectHandler keeps its current semantics, and existing embedders
are unaffected.

Open question

Should these live on IBackend rather than only on the Qt backend? Connection state is a
property of any transport-backed backend, and a UI shouldn't have to downcast to a concrete
type to observe it. The counter-argument is that a purely local backend has no meaningful
connection state, so a base-class hook would be inert for it. I lean toward putting at least
the observation points on the interface with no-op defaults, the way setReconnectHandler
already is — but happy to follow your preference.

Happy to open a PR.