No test covers a zero-length ISO OUT packet in the audio read thread #291

#271 fixes a defect in _ux_device_class_audio_read_thread_entry that no test covers, and it merged without one. This records what a test would have to do, so the gap is tracked rather than remembered.

The defect: a zero length isochronous OUT packet was logged as a frame. A frame length of zero is exactly what marks a slot free, so the reader never drains that slot, while the transfer position advances past it. Each such packet therefore costs one buffer slot for the life of the stream, and a host that sends them routinely — which is normal when there is no audio to send — walks the whole ring.

Ten tests drive this thread today, including usbx_audio10_device_basic_test and usbx_audio20_device_basic_test. None of them sends a zero length packet, so all ten pass with and without the fix. That is the shape worth noting: the thread is well covered for the path where data arrives and not at all for the path where it does not.

A test needs three things:

• A simulated host that sends a zero length ISO OUT packet, interleaved with packets that carry data, so that the before and after states of the ring can be compared across a known sequence.
• An assertion on the frame ring rather than on a status. The fix returns nothing and sets nothing; what changes is that the transfer position does not advance and the slot stays available. Reverting the continue has to fail the test, which means asserting on ux_device_class_audio_stream_transfer_pos or on the count of free slots, not on a return code.
• A second assertion on the frame_done callback, which the skip now bypasses for zero length packets. That is believed correct, since a zero length packet is not a frame, but it is a visible behaviour change for an application that counts callbacks rather than bytes, and nothing currently pins it either way.

The device audio tests already stand up the simulated host and device stack, so this is an addition to that apparatus rather than new infrastructure.