fix!: make concurrent invocations work instead of silently seeing nothing (#22)

Running several one-shot commands at once returned "no results" for queries that
had plenty. Four defects, each of which made a dead session look like an empty
network:

- The peer listener bound its port inside a detached thread and panicked on
  EADDRINUSE, unwinding that thread alone. The process carried on with no
  listener, so no peer could deliver a search response. `Listen::bind` now takes
  the socket before login and falls back to an ephemeral port when the
  configured one is held.
- SetWaitPort advertised the configured port whether or not it was bound, so
  peers dialled a sibling process that discarded responses to tickets it never
  issued. The port the listener really holds is what gets advertised, mapped
  through UPnP, and reported by `whoami` and `serve`.
- A zero-byte read is EOF on a TCP socket, but MessageReader reported it as
  success, so a server that closed cleanly left the actor polling a dead socket.
  It is now an error, and Relogged (code 41) has a handler. The peer actor
  classifies that error: a control connection that was established and then
  closed is a clean disconnect, because peers drop idle sockets while the bytes
  move over their own connection, and reporting an error there fails every
  download queued with that peer including the one streaming. A connection that
  never established keeps the error path, which is what the server-brokered
  fallback reads to know a peer is unreachable.
- A session the server cut off - usually because another process logged in under
  the same name - exited 4, documented as "it worked and found nothing". Callers
  concluded the file was unavailable. Sessions now record why they ended and
  those verdicts become exit 7.

The server allows one session per account, so concurrency still needs a distinct
--username per run; SKILL.md documents that. The listener port needs no such
care any more.

Six e2e tests against soulfind cover it, each of which fails without the fix: a
taken listen port, a displaced session, three clients searching at once under
one configured port, the two CLI equivalents, and a peer that hangs up its
control connection while a transfer is still to come.

BREAKING CHANGE: `Listen::start` is replaced by `Listen::bind` and
`Listen::serve`, so the caller owns the socket and can read the port it actually
bound. `Client::listen_port` and `Client::session_loss` are new.

README.md

@@ -135,6 +135,7 @@ The one-shot commands follow three rules, so they compose with other tools:
 | 4    | the command worked but found nothing                       |
 | 5    | timed out waiting for a response or a transfer             |
 | 6    | a transfer started but did not finish                      |
+| 7    | the session ended mid-command; nothing it saw is reliable  |
 
 #### Commands
 
@@ -464,6 +465,10 @@ forward the port yourself.
   `--listener-port` you chose) to this machine on your router.
 - Pass `--no-listener` to turn the listener (and port mapping) off, or
   `--listener` to force it on when the config file disables it.
+- If another process on this machine already holds that port — the usual case
+  when several one-shot commands run at once — the client takes one the OS
+  picks instead, says so on stderr, and advertises and maps that one. `whoami`
+  reports the port it really holds.
 
 Check whether it works on your network without launching the whole client: