fix(usb_serial_jtag): flush TX FIFO at end of usb_serial_jtag_write (IDFGH-17790)

[MaikVermeulen]

Summary

usb_serial_jtag_write() (the USB-Serial/JTAG VFS write path) emits every byte but never flushes the TX FIFO. The final bytes of a write — and the zero-length packet that terminates a 64-byte-multiple USB transfer — can therefore linger in the FIFO and never be delivered across a USB re-enumeration after a chip reset. On ESP32-C6/H2 this intermittently wedges the host CDC pipe:

• Console (no-driver path): missing printf/log output on cold boot, especially with logging disabled.
• OpenThread RCP (driver-backed path): OpenThread sends every spinel frame via otPlatUartSend → write() → usb_serial_jtag_write, and otPlatUartFlush() is a no-op, so the spinel link goes dead and the host's TLS/handshake never gets a response. Recovery requires a physical unplug.

The fix mirrors the existing '\n' handling in usb_serial_jtag_tx_char_no_driver() and the fsync path, which already flush to "make sure the line doesn't linger in fifo" — we simply flush once at the end of every write.

        s_ctx.tx_func(fd, c);
    }
    usb_serial_jtag_ll_txfifo_flush();   // <-- added
    _lock_release_recursive(&s_ctx.write_lock);
    return size;

Validation

Reproduced and fixed on physical ESP32-C6 hardware via an A/B cold-plug test (physical VBUS power-cycle per iteration, one handshake-over-USB attempt per boot, logging disabled — the condition that exposes the bug). The only difference between the two images was this flush:

Build	Flush	Result
Baseline	absent	~33% timeouts (host never gets a response)
Fixed	present	0 timeouts over 20 consecutive cold-plugs

References

• Closes ESP32-C6/H2 USB_SERIAL_JTAG not initialised correctly when logging is disabled (IDFGH-16276) #17432 (ESP32-C6/H2 USB_SERIAL_JTAG not initialised correctly when logging is disabled)
• Related: openthread/openthread discussion System crashes when we try to enter deep sleep after terminating the BLE( Properly Terminating the BLE as per docs ) (IDFGH-10369) #11627 (USB OT-RCP intermittent replug failures), where the same "flush after sending" fix was identified.

The fix was first posted by me in the discussion on #17432.

[CLAassistant]

All committers have signed the CLA.