Feat/deferred disconnect

[vjan-nie]

feat: defer client disconnect until queued output drains (T4)

Summary

When the server closed a connection that still had data queued in _out — the
motivating case being 464 ERR_PASSWDMISMATCH on a wrong password — the client
received nothing: disconnectClient() closed the fd before the queue
drained. A wrong-password client saw a silent connection drop, no reason given.
That violates the modern IRC spec's MUST (send 464 and/or ERROR before
closing) and is visible in HexChat, the evaluation's reference client.

T4 makes the close deferred: the departure is announced immediately, but the
fd is physically closed only once _out drains via the existing EPOLLOUT
path, or a safety deadline elapses.

Why this is not a revert of T3

T3 deliberately removed two send() calls that ran without a prior poll.
T4 does not bring them back. The deferred close drains through
handleClientOutput — the one send() that is already EPOLLOUT-gated — so it
honours T3's rule and still delivers the reply. Zero new un-polled sends.

Mechanism

disconnectClient() marks the client pending-close, removes it from its
channels immediately (so _out is a fixed snapshot, not growing), and lets the
normal loop drain it. A pending-close client stops reading input — it is
write-only until it dies. Cases that must not defer close immediately via
disconnectClientNow():

• SendQ exceeded — draining toward a reader that by definition isn't reading
  would re-introduce the frozen-reader scenario T6 guards. Immediate close.
• Connection error (RST) — socket already in error; draining is pointless.
• MAX_CLIENTS / "Server full" — never went through disconnectClient in the
  first place; explicitly out of T4's scope (CLAUDE.md corrected accordingly).

A per-client time_t deadline (PENDING_CLOSE_TIMEOUT, 5s prod, injectable for
tests) bounds a client that never drains; on expiry the socket is closed
abortively (SO_LINGER{1,0}), confined to checkPendingCloseTimeouts.

Review history — two rounds, and what they caught

This branch went through two adversarial review rounds. Worth recording because
the fixes are subtle:

• Round 1 found the teardown could be re-entered from an extension's
  onClientDisconnect (use-after-free, reproduced as a real segfault before
  fixing — now guarded by isTearingDown()), and that the deadline test paid a
  fixed 8s sleep (made the timeout injectable).
• A gettimeofday introduced for sub-second test injection was reverted: it
  is neither C++98 nor in the subject's External-functions list. Back to
  time_t/std::time, whole-second injection.
• Round 2 found the deadline test was a placebo — it asserted only
  "eventually closed", so it passed even when the client closed by
  drain-complete rather than by the deadline. Fixed to assert close time falls
  near the injected deadline. Implementing that surfaced two more real issues:
  the probe tracked a raw fd that a new client could reuse (now gated on
  isPendingClose()), and default tcp_rmem (128KiB) exceeds MAX_SENDQ
  (64KiB), so no sub-SendQ payload ever actually froze — the client's
  SO_RCVBUF is now shrunk to 4KiB to force genuine backpressure.

Verification

• Fire drill (positive): wrong password now delivers 464 before close — fails
  against pre-T4, passes now.
• Fire drill (deadline test): with the probe draining fast the test FAILS
  (close in ~20ms, below the deadline floor); frozen, it PASSES, stable 10/10.
• No double-free: 4 finalizeDisconnect sites traced against 5 trigger paths,
  guards hold.
• T6 anti-regression 15/15 (--gtest_repeat=5); full suite 456/456; three tiers
  -Werror clean via make verify-tiers; audit and normalize clean.

Note on the test count

"456 assertions" is PostMan's assertion counter, not a test-case count: 155 are
real product tests, 301 are PostManTruncationRegression's own self-checks.