The SocketSelector just does a socket select, which basically waits for a socket to become readable.
A client disconnecting from a socket doesn't really make the socket readable, so the selector correctly doesn't notify of any sockets being ready.
Then then however still leaves you with the problem of having sockets in the selector that are potentially disconnected already. TCP is a very old protocol designed around problems from the 70s, as such there's no proper defined "disconnect" state or event and as such SFML also doesn't really provide anything specifically in that direction.
You could try to read from the sockets in the selector and it would return a disconnected status, but if you're in a blocking setup, you might risk blocking on the read if the connection is still alive (hence why you're already using a selector).
The alternative is to define a custom connection timeout. If a client isn't sending any updates within a given time frame, then the connection is closed from the server side.
This means, you'll have to track the last read times for each socket and implement a sort of keep-alive protocol, so ensure that the connection is kept open, even if you don't have any content to send.
Maybe if you write code for one specific platform, there would be additional ways to detect a disconnect in more details, but one cannot stress enough that SFML's network module is very outdated in terms of network programming, and for anything more serious, one should consider ASIO or similar.