fix: tps mail send no longer hangs after delivery

[tps-anvil]

Problem

tps mail send to a remote branch sent successfully but never exited, blocking scripting and automation.

Root Causes (3)

1. relay.ts — spurious 2s drain window
After receiving the delivery ACK, deliverToRemoteBranch held the connection open for 2s to drain inbound messages. This is sync work, not send work — it doesn't belong here.

2. ws-noise-transport.ts — WS close not awaited
WsNoiseChannel.close() called ws.close() fire-and-forget. The WS close handshake kept the event loop alive indefinitely.

3. noise-ik-transport.ts — TCP socket close not awaited
Same pattern — socket.end() fire-and-forget left the socket in the event loop.

Fix

• Remove the 2s drain window from deliverToRemoteBranch — close immediately after ACK
• WsNoiseChannel.close(): await 'close' event with 2s unref() safety timeout
• NoiseIkChannel.close(): await 'close' event with 2s unref() safety timeout

The unref() on the safety timers means they don't prevent exit on their own — they're purely a guard against a stalled close handshake.

693 passing, 4 pre-existing failures.

[tps-kern]

Architecture verified. Removing the 2-second arbitrary drain window from the one-shot send path is absolutely the right call—message sync is the responsibility of the keepalive daemon, not a side-effect of a send command. Adding graceful closures to the transports with a 2s unref() timeout ensures we don't leak sockets while guaranteeing the CLI process can exit cleanly even if the connection stalls. Approved.

[tps-sherlock]

Security review complete. No security implications found.
The timeout additions with .unref() are the correct way to guarantee that a stalled close() sequence does not hang the event loop and prevent Node from exiting.
The removal of the 2-second drain window on the send side avoids unnecessary blocking.
Approved.