docs(player): note that the speaker socket opens lazily

The readback early-stop keys on `webSocketConnected`, which is the service's
socket to the speaker and is opened on first fetch or control of a device
rather than at discovery. Worth a line where the flag is already referenced,
since it makes the first click after loading a device behave differently from
later ones.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md

@@ -106,7 +106,10 @@ seconds later, surfacing as a transition to an error source
 - **Bounded readbacks** at 2s, 5s and 10s are the fallback for a speaker whose
   events are not arriving. They stop as soon as a confirmation arrives *and*
   the readback reports a live event stream, so a confirmed selection normally
-  costs one request rather than three.
+  costs one request rather than three. That signal is `webSocketConnected`,
+  which reports the service's own socket to the speaker; it is opened lazily
+  on first fetch or control of a device, so the very first click after
+  loading one can still take all three.
 - Readbacks use `GET /devices/{id}/now-playing`, which refreshes only
   `/now_playing`. The full device fetch runs a complete status poll: six
   sequential speaker calls plus `/getGroup` on a stereo-capable model, to