[Antruly]

What this PR contains

This branch carries the pending 1.8.7 transport line plus one new fix:

1. 78eb5e0 — Fix a crash in http_client when the directory is unreachable
2. 4000484 — docs: bump README version to 1.8.7
3. e76f693 — h3: bound an extended-CONNECT stream's outbound queue
4. e67f731 — docs: add the v1.8.7 release notes
5. b8b29b9 — tcp: free the TLS object when a client dies inside its loop (new)

The rest of this description covers commit 5.

Problem

~uvcpp_tcp_client() takes the "loop is running" branch for every client
destroyed from a server close callback, and that branch did:

tls_ssl_ = nullptr;

without deleting the uvcpp_ssl allocated by enable_tls(). Every accepted
TLS connection therefore leaked one uvcpp_ssl plus its OpenSSL state.

Measured on a live moLink Server 0.3.4 (device + admin listeners TLS):

• valgrind, 20 TLS connections: 1,172,840 (1,280 direct, 1,171,560 indirect) bytes in 20 blocks definitely lost, allocated in
  uvcpp_tcp_client::enable_tls ← uvcpp_tcp_server::finish_accept ←
  uvcpp_stream::callback_connection.
• 500 fresh TLS connections to GET /healthz: RSS +26 MB, private +31 MB.
  The same 500 requests over one keep-alive TLS connection, or over plain
  HTTP, are flat.
• The service grew 12–14 MB/min with no established connections, because
  clients heartbeat over short-lived HTTPS connections.

Fix

Keep the pointer in a local and settle it by handle state:

• handle already detached (or absent): delete immediately — no TLS callback
  can still be on the stack;
• handle alive and a uv_close can be scheduled: hand it to the existing
  tcp_->close(...) completion, which runs after the current frame unwinds;
• close slot already taken: leave it behind (that branch already logs a
  wrapper leak).

Verification

• valgrind, 20 TLS connections: the 20 per-connection blocks are gone (only a
  one-off 64 KiB read buffer remains at shutdown).
• 500 fresh TLS connections: RSS +1.3 MB (allocator noise) vs +26 MB before.
• The same patched library is what is currently running on the production
  moLink server, where the memory curve is flat at ~17–19 MB under real
  traffic.