usbd: handle a refused transfer without halting, and report it

A refused transfer is a recoverable condition - a new setup superseding a
control response, for instance - rather than a bug, but every failure path
treated it as one. TU_ASSERT carries TU_BREAKPOINT, which is gated on a debugger
being attached rather than on CFG_TUSB_DEBUG, so on a rig where a probe is
always attached it halted the CPU even in release builds. Use TU_VERIFY on the
control transfer paths, including the multi-packet data stage continuation, and
drop the breakpoint from the endpoint transfer failure arm, which already marks
the endpoint ready again so the next transfer can proceed.

The result of usbd_control_xfer_cb() was separately dropped on the floor,
leaving EP0 neither armed nor stalled and nothing recorded. It is logged now,
and deliberately not stalled: a DCD refuses an EP0 prime when a newer setup is
already latched, and EP0 stalls are cleared by hardware when that setup arrives,
so a stall issued here would land after the auto-clear and stall the transfer
that superseded this one. The pending setup re-drives EP0 by itself.

0 files changed, 0 insertions, 0 deletions