[bug fix] driver_vive: fix three USB transfer retry/error-handling bugs in handle_transfer

[rocketmark]

Summary

handle_transfer()'s USB transfer retry/error-handling logic has three bugs: the timeout path never resubmits below the disconnect threshold, error_count is incremented twice per call, and the error path always disconnects regardless of retry outcome. A fourth, related bug in the same path: a STALL is retried without clearing the halt condition first.

Demonstration

Trigger: ordinary USB transfer errors (a timeout, a stall) during normal operation — not a rare or exotic condition.

BEFORE fix:
status = LIBUSB_TRANSFER_TIMED_OUT, consecutive_timeouts = 1 (below the disconnect threshold)
libusb_submit_transfer() never called
Result: endpoint stops producing further completions, permanently

status = LIBUSB_TRANSFER_STALL
error_count++ → 1
error_count++ (again, inside the if condition) → 2
libusb_submit_transfer() called, resubmit succeeds
no return — falls through to goto disconnect anyway
libusb_clear_halt() never called
Result: device disconnects after a single transient STALL; error_count
reaches the threshold in half the intended number of errors

AFTER fix:
status = LIBUSB_TRANSFER_TIMED_OUT, consecutive_timeouts = 1
libusb_submit_transfer() called
Result: endpoint resubmitted, keeps operating

status = LIBUSB_TRANSFER_STALL
libusb_clear_halt() called
error_count++ → 1 (single increment)
libusb_submit_transfer() called, resubmit succeeds, return
Result: device retries up to the intended 10 consecutive errors before
disconnecting, clearing the halt condition first each time
Impact

Reachable any time a USB transfer doesn't complete cleanly — a timeout, a stall, any transient bus error. This is the normal error-recovery path, not an edge case. As it stands, a single STALL disconnects the device outright instead of retrying, and any endpoint that times out even once stops producing further completions permanently, since nothing ever resubmits it.

Change

One file, src/driver_vive.libusb.h. Three changes in handle_transfer(): (1) resubmit the transfer before returning on a sub-threshold timeout instead of just returning, (2) a single error_count++ instead of two, with a return after a successful resubmit instead of always falling through to goto disconnect, (3) call libusb_clear_halt() before retrying a STALL. Includes a 3-case regression test (driver_vive_retry_test.c) against a fake libusb (mock_libusb.c), reproducing each bug independently and without hardware.

Found via

Found while auditing handle_transfer()'s retry/error-handling logic for a related reentrancy issue in the same function (see the companion PR). Confirmed each of the three bugs independently with a deterministic test harness rather than relying on a specific field observation.

[rocketmark]

Closing — two of the three fixes here (error_count double-increment, missing return after a successful resubmit) overlap with #372, which found the same missing-return bug via an actual observed crash (libusb_free_transfer() on a still-in-flight transfer). I'll resubmit a trimmed PR with just the two fixes #372 doesn't cover: the timeout path not resubmitting below the disconnect threshold, and the missing libusb_clear_halt() before retrying a STALL.