Sixteen 9P connections, and the next one is told there is no room instead of being reset

Four slots ran out under scripts plus a mount, and the fifth client was closed without a word, which through a mount looks exactly like a dead session. pardes now serves sixteen, and builds against cloud9 09b77cf, whose runner answers the Tversion of a client it cannot seat with an Rerror "too many connections" and tells pardes, which logs `err - 9p: too many connections`. QUIC keeps its own sixteen and still just closes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 4 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index e989aba8..12e94b8d 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -45,8 +45,10 @@ IPv4/IPv6 addresses, not DNS names. Listener port zero chooses a free port;
 All connections have session access, including `os`. TCP is unencrypted.
 QUIC uses an ephemeral TLS identity without peer verification or login.
 It carries 9P2000 on one bidirectional stream with ALPN `pardes-9p`.
-Unix and TCP connections share four slots served by cloud9's `std.Io`
-runner; QUIC has four of its own on the editor's poll loop. OpenSSL's
+Unix and TCP connections share sixteen slots served by cloud9's `std.Io`
+runner; QUIC has sixteen of its own on the editor's poll loop. A client
+that finds every Unix/TCP slot taken gets an Rerror `too many connections`
+to its Tversion, and the log an `err - 9p: too many connections` record. OpenSSL's
 internal buffers are separate, dynamically allocated memory.
 
 [Plan9port's client](https://9fans.github.io/plan9port/man/man1/9p.html) can