feat!: establish network connection observer services

[MartinCupela]

Description of the changes, What, Why and How?

The SDK told users "you're offline" when their internet was fine. The offline banner was
driven by WebSocket health, and a socket dies for reasons unrelated to the network — the
server closes it, a token expires, a keep-alive times out. It also missed the opposite case:
when a phone really loses signal, the socket takes up to 35s to notice.

Three facts, kept apart

Question	Answered by
Does this device have a network?	client.networkConnection — new
Is our WebSocket up, and on which connection id?	client.wsConnection
Have we finished re-syncing after a reconnect?	client.connectionRecovery, which dispatches connection.recovered

Apps can now say "you're offline" for the first network connection loss and "reconnecting…" for the WS connection loss.

Telling the SDK about the network

One function that subscribes to whatever the platform offers:

client.config.set({
  client: {
    networkConnection: {
      statusListenerRegistrar: (onStatusChange) => {
        onStatusChange(navigator.onLine); // report the current value immediately
        const handle = () => onStatusChange(navigator.onLine);
        window.addEventListener('online', handle);
        window.addEventListener('offline', handle);
        return () => {
          window.removeEventListener('online', handle);
          window.removeEventListener('offline', handle);
        };
      },
    },
  },
});

Browsers get that registrar for free — the SDK installs it itself. On React Native, in Node
or during SSR you supply one, and until you do client.networkConnection.isOnline is
undefined rather than false: the SDK won't guess, because a fabricated "online" can't be
told apart from a real reading.

So isOnline has three values, and the code deciding whether to render an offline banner has
to handle all three:

if (client.networkConnection.isOnline === false) {
  // definitely offline — show the banner
}

if (!client.networkConnection.isOnline) {
  // WRONG: `undefined` is falsy too, so this also shows the banner when the status is
  // unknown — a React Native app with no registrar would show "you're offline" forever
}

You don't have to supply a registrar at all. The socket still connects and reconnects, messages
still send, queries still run: the SDK never checks network status before doing any of that. It
uses it for one thing only — noticing a dropped connection sooner than the socket's own
35-second keep-alive check would.

Bugs fixed along the way

Independent of the feature, found while auditing it, each its own commit:

• Channels were watched against dead connections. "Watching" a channel means asking the
  server to push that channel's realtime events to this client, and the server ties the
  subscription to a WebSocket by its connection id. channel.watch() checked that the client
  had such an id before asking. But the id is set once when the socket connects and is never
  cleared, so during a reconnect the check still saw the previous id and went ahead — subscribing
  over a socket that was already gone. The channel then believed it was watching while the server
  sent it nothing.
• A backgrounded app came back to a stale thread list. ThreadManager reloaded only if it had
  seen connection.changed { online: false } — an event client.closeConnection() never
  dispatches, and closeConnection() is the path a mobile app takes when backgrounded. It also
  never reset the lastConnectionDropAt timestamp it recorded, so after the first drop of a
  session that check stopped gating anything at all.
• connection.recovered fired when nothing had recovered. Recovery reloads every open channel
  with Promise.allSettled, so one failure doesn't stop the rest — but a network drop mid-recovery
  could fail all of them, and the event was dispatched regardless. The UI SDKs mark messages read
  when they see it, so they marked messages read that had never been fetched.
• Replaced sockets were abandoned rather than closed. client.openConnection() overwrote the
  current socket without disconnecting it, so the old one kept its keep-alive timers and its own
  reconnect logic running alongside the new one.

Breaking changes

Each item appears in a BREAKING CHANGE: footer on the commit named.

feat!: derive network status from a platform listener, not the WebSocket

Before	Now
connection.changed / connection.recovered carried only online	both carry connection: 'network' | 'ws' — check it first, or a socket drop on a working network reads as the device going offline
StableWSConnection.isHealthy	.isOnline
client.defaultWSTimeout	client.config.set({ client: { wsConnection: { connectTimeoutMs } } })
WebSocketImpl / wsUrlParams / wsConnection client options	wsConnection config: webSocketImpl / urlParams / connection
client._getConnectionID()	client.wsConnection.connectionID

Unlike the fields and options they replace, these survive a reconnect.

fix: reload the thread list on reconnect without a self-owned drop flag

Before	Now
client.threads.state.lastConnectionDropAt	client.wsConnection.state.lastOfflineAt

feat!: wait for a live socket in channel.watch() and queryChannels()

Both now wait for a live socket (up to connectTimeoutMs, 15s) instead of returning unwatched
data, and throw if it doesn't come back. The channel then stays unwatched, offline support
renders it locally, and the next reconnect reloads it. An explicit watch: false is still
honoured. client._hasConnectionID() is removed.

⚠️ If you have tests that mock a connected client, this is the one to watch. A fixture
faking a connected user without a live socket will now see watch() wait and throw. One line
to fix — mark the socket up — but it broke 552 tests in stream-chat-react first. The error
names it: Cannot wait for a WebSocket connection: none has been opened.

Behaviour change, no API change: connection.recovered is withheld when the network drops
mid-recovery, so you'll stop seeing it for recoveries that recovered nothing. Unaffected when
no registrar is installed.

Ready to paste into the squash commit message — these are BREAKING CHANGE: footers in the
form commitlint and semantic-release parse, verified against this repo's config.

BREAKING CHANGE: `connection.changed` and `connection.recovered` now carry a `connection:
'network' | 'ws'` field. Narrow on it before reading `online`, or a socket drop on a working
network reads as the device going offline.

BREAKING CHANGE: `StableWSConnection.isHealthy` is renamed to `isOnline`.

BREAKING CHANGE: `client.defaultWSTimeout` is removed, along with the `WebSocketImpl`,
`wsUrlParams` and `wsConnection` client options. They move to `client.wsConnection.config` as
`connectTimeoutMs`, `webSocketImpl`, `urlParams` and `connection`, set with
`client.config.set({ client: { wsConnection: { … } } })`. Unlike the fields and options they
replace, these survive a reconnect.

BREAKING CHANGE: `client._getConnectionID()` and `client._hasConnectionID()` are removed. Read
`client.wsConnection.connectionID`, or `client.wsConnection.isOnline` where the intent was "is
the connection up" — the connection id is never cleared, so it stayed truthy through a drop.

BREAKING CHANGE: `ThreadManagerState.lastConnectionDropAt` is removed. Read
`client.wsConnection.state.lastOfflineAt`, which is written on every status transition,
including the `disconnect()` path the event is silent about.

BREAKING CHANGE: `channel.watch()` and `client.queryChannels()` now wait for a live WebSocket,
up to `connectTimeoutMs` (15s by default), instead of silently returning unwatched data, and
throw if one does not arrive. The channel is then left unwatched, offline support renders it
from the local database, and the next reconnect reloads it. An explicit `watch: false` from the
caller is still honoured. Test fixtures that fake a connected user without a live socket will
see `watch()` throw `Cannot wait for a WebSocket connection: none has been opened.`

BREAKING CHANGE: `connection.recovered` is no longer dispatched when the device network drops
while a recovery is running, because every reload in it can have failed. Work keyed off that
event will correctly stop running for recoveries that recovered nothing. Unaffected when no
network status registrar is installed.