Show an IRC listener user what their session sends from other clients (closes #179)

The IRC listener's relay dropped every line sent under the connection's own nick, so a user on the web client and an IRC client at once never saw on IRC what they did from the web client. The relay now drops nothing by nick. Instead the fan-out skips only the sending client's own queue: the IRC listener passes its own client, whose handler already wrote the echo, and the HTTP API skips none. Channel messages and PARTs now reach the sender's other clients, so an HTTP client gets its own PART event; neoirc-cli ignores it, as it already shows its own part. README.md names the commands covered.

Judgement call: a PRIVMSG or NOTICE sent on an IRC connection is not echoed back to it, as in IRC.

Model: opus-5-5

README.md

@@ -268,10 +268,15 @@ rules). Case-sensitive comparison is unambiguous.
 A single user session can have multiple clients (phone, laptop, terminal).
 
 - Each client gets a **separate server-to-client (S2C) message queue**.
-- The server fans out messages and events from other users, and the user's own
-  DMs and the channel messages it sends over the HTTP API, to every client queue
-  for that user session. Replies to a command (numerics) go only to the client
-  that sent it.
+- The server fans out messages and events from other users to every client queue
+  for that user session.
+- When the user sends a `PRIVMSG`, `NOTICE`, `JOIN`, `PART`, `NICK`, `TOPIC`,
+  `MODE` or `KICK` from one of its clients, the resulting event goes to every
+  client queue of the user's own session, as well as to the other users it is
+  meant for. The one exception is an IRC listener connection that sent the
+  command, which gets nothing queued for it: it has already sent its user the
+  echo, or, for `PRIVMSG` and `NOTICE`, IRC sends none.
+- Replies to a command (numerics) go only to the client that sent it.
 - `GET /api/v1/messages` delivers from the calling client's specific queue,
   identified by the auth cookie.
 - Client queues have **independent expiry/pruning** — one client going offline
@@ -744,7 +749,7 @@ Leave a channel.
 {"command": "PART", "to": "#general", "body": ["goodbye"]}
 ```
 
-**S2C (broadcast to the other channel members):**
+**S2C (broadcast to all channel members, including the departing user):**
 
 ```json
 {
@@ -760,9 +765,8 @@ Leave a channel.
 
 **Behavior:**
 
-- The PART event goes to the other channel members, not to the departing user;
-  the HTTP response confirms the part. (The IRC listener echoes the PART to its
-  own connection.)
+- The PART event goes to every channel member, the departing user's own clients
+  included. (An IRC listener connection that sends a PART echoes it itself.)
 - If the channel is empty after the user leaves, the channel is **deleted**
   (ephemeral channels).
 - If the user is not in the channel, the server returns an error.