fix(net-tcp-server): prevent use-after-free crash in UvLoopHolder destructor

[Ante042]

Summary

UvLoopHolder::~UvLoopHolder() can crash with Assertion failed: 0 (../deps/uv/src/unix/core.c: uv_close: 234) due to a race condition during shutdown.

Root cause

The destructor creates a stack-allocated uv_async_t, registers it with the loop, sends a signal, then calls m_thread.join(). The loop thread sees m_shouldExit == true, destroys the loop (m_loop = {}), and exits. After join() returns, the destructor calls uv_close() on the stack-allocated handle — but the loop is already destroyed and the handle's internal type field is corrupt. libuv's uv_close hits the default branch in its type-switch and asserts.

Timeline:
  Destructor thread              Loop thread
  ──────────────────             ──────────────
  m_shouldExit = true
  m_loop->stop()
  uv_async_init(&async)
  uv_async_send(&async)
  m_thread.join() ───────────►   exits while loop
       (blocks)                  m_loop = {}  ← loop destroyed
       (returns) ◄──────────     thread exits
  uv_close(&async) ← CRASH

Fix

• Reuse the existing m_async member to wake the loop thread — no stack-allocated handle needed.
• Close m_async from within the loop thread (where libuv requires handle closure to happen) and run the loop one final time to process the close callback.
• Remove the post-join uv_close() call that operated on a dead loop.

Observed impact

This crash was observed on a production FXServer (Linux, 64-slot) running artifacts 27055 and 27722. The crash dump signature:

Assertion failed: 0 (../deps/uv/src/unix/core.c: uv_close: 234)

The bug exists in all current artifacts — the file has never been modified since creation.

Testing

The fix is a minimal, targeted change (9 lines added, 12 removed) to a single file. The async handle lifecycle now follows libuv's threading rules: handles are closed from the thread that owns the loop, before the loop is destroyed.