mux a run --quic died once on the macOS guest with no output (xos leg 6, intermittent)

open   by a73x

Seen once on 2026-09-04, in the first `make xos` run against the bridged tart guest
(MAC_BOX=admin@192.168.0.87, aarch64, the Mac build from squirtle at 7f269f3a; LINUX_BOX
the x86_64 musl daemon on mux-lan). Leg 6, mac-to-linux-quic, runs on the guest:

    MUX_KEY_FILE=$HOME/xos/key $HOME/.local/bin/mux a run --quic 192.168.0.37:4433 \
        --key $HOME/xos/key --timeout 20000 'echo m2lq-$$'

right after leg 5's ptyclient attached to the same daemon over QUIC and detached. The
command exited nonzero with an EMPTY stdout and nothing on stderr, ~55 s into the run
(so not the 120 s wrapper). Every verb failure in muxa.zig prints `{"error":...}` on
stdout before exiting, so an empty capture is a death by signal, not a refusal.

Not reproduced: the same leg passed by hand 5/5 through the gate's own `ssh ... /bin/sh -s`
transport (0.2-0.3 s each), and the whole gate then passed 4/4 (xos runs 2-5), 10 legs each.

The gate now captures the exit code and stderr ON the box for this leg
(`test: the xos QUIC agent leg reads mux a's exit code on the box`), so the next occurrence
says which signal. Suspects worth checking when it recurs: a Darwin SIGPIPE path in the QUIC
client (the UDP socket has no SO_NOSIGPIPE; `client_os.sendNoSig` covers the stream sockets),
or a crash in the wolfSSL PSK handshake on a connection reused right after a CONNECTION_CLOSE.