usbtmc: document why the trigger re-arm result is ignored

A false return from tud_usbtmc_start_bus_read() here does not mean arming
failed: it means the endpoint is already armed, either because the
application re-armed it from its trigger callback or because a transfer is
still queued (usbd_edpt_xfer() reports failure when the endpoint is busy).
Both cases end in STATE_IDLE, so the state cannot disambiguate them either,
and stalling on the result would halt a healthy endpoint.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/class/usbtmc/usbtmc_device.c

@@ -511,6 +511,9 @@ bool usbtmcd_xfer_cb(uint8_t rhport, uint8_t ep_addr, xfer_result_t result, uint
               usbd_edpt_stall(rhport, usbtmc_state.ep_bulk_out);
               return false;
             }
+            // Result deliberately ignored: false here means the endpoint is already armed - either the
+            // application re-armed it from its callback, or a transfer is still queued - not that arming
+            // failed. Stalling on it would halt a healthy endpoint.
             tud_usbtmc_start_bus_read();
 
             break;