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

The relay dropped every PRIVMSG, NOTICE, JOIN, PART, NICK, QUIT, TOPIC,
MODE and KICK sent under the connection's own nick, so an IRC listener
connection never saw what its session did from another client. The
relay now drops nothing by nick. Instead, the service methods that fan
out a user's own command take the client whose queue to skip: the IRC
listener passes its own client, which has already written the echo, and
the HTTP API passes 0. Channel messages and PARTs now also go to the
sender's own session, so the HTTP handler no longer queues the
channel-message echo itself, SendChannelMessage no longer returns the
message's row ID, and neoirc-cli ignores the PART event for its own
part, which it has already shown.

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.