Address review: better emphasize send() vs recv() behavior

Remove informal 'I repeat:' phrasing. Restructure paragraph to clearly
contrast recv() returning 0 bytes (a deliberate signal of disconnection)
with send() raising OSError (an error condition — should never be called
on a broken socket).

Co-authored-by: bkap123 <bkap123@users.noreply.github.com>

Author: Gh-Novel

Doc/howto/sockets.rst

@@ -167,10 +167,11 @@ request, then reads a reply.  That's it. The socket is discarded. This means tha
 a client can detect the end of the reply by receiving 0 bytes.
 
 But if you plan to reuse your socket for further transfers, you need to realize
-that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* I repeat: if a
-``recv`` returns 0 bytes, the connection has been broken.  A ``send`` on a
-broken connection will raise an :exc:`OSError` instead.  If the connection has
-*not* been broken, you may wait on a ``recv``
+that *there is no* :abbr:`EOT (End of Transfer)` *on a socket.* If a ``recv``
+returns 0 bytes, the connection has been broken. In contrast, you should never
+call ``send`` on a broken socket, as it will raise an :exc:`OSError` rather than
+returning 0.  If the connection has *not* been broken, you may wait on a
+``recv``
 forever, because the socket will *not* tell you that there's nothing more to
 read (for now).  Now if you think about that a bit, you'll come to realize a
 fundamental truth of sockets: *messages must either be fixed length* (yuck), *or