docs(quic): what ~ClientQUIC lets finish before it closes

The README and the consumer notes say that a reply sent on a stream let
go just before deleting the connection still arrives, and the agent
notes add the gotcha with the test that guards it, and count 39 tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -121,7 +121,7 @@ Crafter::ListenerQUIC listener("127.0.0.1", 0, "myproto/1", creds, [](Crafter::C
 
 Keep the callback short: it runs on the msquic worker, so no `*Sync` call and no deleting a *different* connection from inside it. If the connection had already closed when `OnClosed` was called, it fires as a pool task instead, never inside `OnClosed`. Once `~ClientQUIC` has begun it never fires, and the destructor waits for one already running on another thread, as `std::stop_callback` does, so don't destroy a connection while holding a lock its callback takes. A client-side `ClientQUIC` has `OnClosed` too.
 
-`~ClientQUIC` waits, up to 1 s and about a round trip when the peer is there, for its close to reach the peer, so a server learns of a client that went away at once rather than at its idle timeout.
+`~ClientQUIC` waits, up to 1 s and about a round trip when the peer is there, for its close to reach the peer, so a server learns of a client that went away at once rather than at its idle timeout. Before that it lets the streams already stopped finish, bounded the same way: a reply sent with `SendAsync(..., finish = true)` on a stream that was then let go still arrives when the connection is deleted right after.
 
 #### Sending without a thread