test(node): run the connection processes on Windows, source and frozen

Connection processes and the larger UDP receive buffer were written and
measured on Linux; nothing had run on Windows, and `meshbay-node.exe
webrtc-worker` had never run from a frozen build on any system.

- test_connection_processes.py failed on Windows (8 tests): the selector
  loop the suite uses there cannot start a process. A test marked
  `daemon_loop` now runs on the daemon's own loop, chosen through
  pytest-asyncio's loop factories.
- The build starts both frozen executables as connection processes and
  carries a connection through each (smoke-connection-process.py). The
  daemon's own smoke test never signs in to a hub, which is when the
  processes start.
- The warning for a receive buffer below what was asked named
  net.core.rmem_max on every system; it names it on Linux only. Windows
  grants the 4 MB.

Measured on an installed build in service mode, docs/WINDOWS-PORT.md §5.12:
two processes at startup and on a live change, a browser's handshake, chat,
a 200 MB download over 8 connections across both processes, an upload, a
video stream, and stop, restart and start leaving no process behind.

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

1 files changed, 4 insertions, 2 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index d0b5475..0703993 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1463,7 +1463,10 @@ dies takes its own connections with it, which their clients see as a dropped
 connection and reopen, and is replaced at the next offer. The loopback socket is
 TCP because that is the one transport the event loop offers identically on every
 platform; a process proves it is the one the node started by returning 32 random
-bytes handed to it on its standard input.
+bytes handed to it on its standard input. A frozen node (the Windows build) has
+no interpreter to start one with and starts a copy of itself,
+`meshbay-node.exe webrtc-worker`, which the build runs for both of its
+executables (`packaging/win/smoke-connection-process.py`).
 
 **Uploads met the same wall from the other side.** A browser 22 ms away uploaded
 at 6.5 MB/s, with no core busy on either machine and no loss in the node's log.
@@ -4465,7 +4468,6 @@ process runs it — `systemctl --user` on Linux, Task Scheduler on Windows.
 | **A folder renamed on the node's disk empties until the next reconciliation** | Seen live (2026-10-10, ntfs3): renaming a 2,441-file folder inside a root made the watcher drop every entry under the old path and announce none under the new one, so the group read as empty, and the loop was busy long enough for the hub's keepalive to time out. A restart (full scan) brought them back. A directory moved within a root should rescan its new subtree at once, not wait for the periodic scan |
 | **A photo deleted from the group comes back after a reinstall** | The backup's memory of what it sent is the phone's ledger (§9.12); a reinstall or cleared data empties it, and the folder no longer holds the deleted photo, so it is sent again. Clean fix: the node keeps a tombstone per folder on `file_delete` (name, size, SHA-256 taken before deleting), the index carries them, and the backup records a match as sent. Not done: a protocol field and a node table for a rare case |
 | **`connection_processes` has no CLI verb** | Set from the Node page or `node.toml`; `meshbay-node` has no command for it, unlike the transfer caps |
-| **Connection processes are untested on Windows and in a frozen build** | The frozen node starts them as `meshbay-node webrtc-worker`; written, never run there |
 | **A connection process does not slow a peer the node cannot keep up with** | What a process receives is forwarded to the node unbounded. An upload is bounded by its own rate, 5 to 6 MB/s a connection, so it would take a node stalled for seconds to matter |
 | **The home page says "No groups yet" when the hub cannot be reached** | An unreachable hub reads as an account with no groups, rather than as an error |
 | **`meshbay-node init` says "Settings → Link Node"** | The control is on the Profile page, as QUICKSTART says |