Fix the document UI's TCP connection: five compounding bugs left it unable to serve a guest

[peacedudes]

The document UI's TCP (Network) connection looked functional but couldn't
actually serve a guest — five small bugs in DriveWireTCPDriver /
TCPCommsView compounded so that no byte ever reached the protocol host and
no response ever reached the wire. Found while pointing a live NitrOS-9
system at the dashboard.

The bugs

1. Incoming bytes never reached the host. readLoop() routed network
   input to dataAvailable(host:data:) — the delegate output callback —
   which only hex-dumped it. Nothing called host.send(data:), so the
   protocol engine never saw guest traffic. Fixed: the read loop now feeds
   host.send(data:) on the main queue.
2. Responses were never written back. dataAvailable ended with a
   commented-out serial-driver leftover (// serialPort?.send(data)), so
   host responses (DWINIT capability byte, sector data, time) were dropped.
   Fixed: it now writes to the output stream via send(data:), which also
   handles partial writes instead of ignoring the write return.
3. The read loop exited the moment the socket went quiet.
   while !quit, ..., stream.hasBytesAvailable made "no bytes pending" a
   loop-exit condition — with the loop started right after connect(),
   it usually exited before the guest said anything. Fixed: idle now sleeps
   and re-polls; only EOF/error ends the loop.
4. stop() latched quit = true forever, so any reconnect (including
   the didSet-triggered ones) started a read loop that exited
   immediately. Fixed: connect() clears the flag.
5. The Connect button only worked by side effect. It assigned
   ipAddress/ipPort and relied on their didSet observers to
   reconnect — so clicking Connect with unchanged values did nothing
   (the workaround was editing a field to force a change), and changing
   both fields reconnected twice, once to a half-updated endpoint. Fixed:
   a connect(ipAddress:ipPort:) method sets both silently and connects
   once, and the button calls it. TCPCommsView now also observes the
   driver, so the connection status label updates when the state actually
   changes rather than on the next unrelated redraw.

Verification

Live end-to-end: NitrOS-9 EOU (dw_becker) booted under XRoar, bridged to
the app's outbound TCP connection with a small localhost relay (both XRoar's
becker cart and this driver dial out, so a two-listener relay marries them).
With these fixes the dashboard answers OP_DWINIT with the capability byte,
serves OP_TIME, and the activity log and telemetry track the guest's boot
traffic in real time. Build also verified directly on this branch.

🤖 Generated with Claude Code