ACK mailbox messages + logging fixes

[technobly]

Problem

• When running the wiring/sleep20 suite against a device, the runner intermittently saw UsbError (LIBUSB_TRANSFER_STALL) on the control IN that reads a mailbox message. The runner treated that as a request failure, closed the device, and on the next iteration _open() triggered a kernel iSerial probe that re-hit the same xhci_hcd bug, turning one transient stall into a multi-second cascade that escalated to a fixture-reset of both DUT and tester and desynced the suite.
• Separately, cycleUSBwithPortPath silently no-op'd when uhubctl wasn't configured or installed, but its four call sites in device.js logged "Cycled USB hub.port device is attached to" either way, so logs claimed a recovery had happened when it hadn't.

Solution

• Add ackMailbox(id) that issues a c:'A' request to the device after each successful readMailbox. This is what completes the device-side mailbox entry and, by inserting a vendor control transaction (whose IN reads carry no payload, so they're the kernel-bug-safe variety) between the heavy-payload readMailbox and getStatus exchanges, suppresses the phantom-EPIPE stalls the kernel otherwise produces.
• Reorder waitTest's mailbox handler so local state (expectingReset/expectingSafeMode/mboxMessages) is set before await ackMailbox, and setWillDetach(true) + close() are deferred until after the ACK lands. Calling setWillDetach(true) first made _open()'s isAttached() return false and broke ACK retries.
• Stop closing the device on transient UsbError in _request. Closing forced an _open() cycle whose iSerial probe re-triggered the kernel bug; leaving the handle open lets the next request retry cleanly.
• Broaden the in-window UsbError swallow in waitTest's status-request path beyond safe-mode so a single transient stall reports STATUS_RUNNING and retries, instead of escalating to a fixture-recovery reset.
• Have cycleUSBwithPortPath return true/false to indicate whether the cycle actually happened, and update the four call sites in device.js to log "Hub-cycle disabled, ..." (warn) when the feature is off instead of misleadingly claiming a cycle succeeded.

Testing

• Paired with the companion device-os PR, four consecutive runs of wiring/sleep20 on the affected Linux rig: 46/46 tests passing, zero application-level USB stalls in usbmon captures.

References

• Branch: fix/mailbox-usb-stall (in device-os-test-runner)
• Companion PR: [test] fixes spurious mailbox/USB stalls during pre-sleep handshake device-os#2923 on fix/test-runner-mailbox-usb-stall