fix(device): release every claimed interface and stop the status transfer on close

[andrescera]

What

uvc_close() left a UVC camera's kernel driver detached, so its /dev/videoN never came back — only a manual USB unbind/bind recovered it. Two independent teardown defects:

1. The VideoControl status interrupt transfer was never stopped. uvc_open_internal() submits it whenever the VideoControl interface carries a status endpoint (optional in UVC, present on most cameras), and _uvc_status_callback() re-arms it after every completion. uvc_close() never cancelled or freed it, so it kept re-arming while the close released that same interface and handed it back to uvcvideo.
2. Only the VideoControl interface was released. uvc_get_stream_ctrl_format_size() claims the streaming interface before probing and returns UVC_ERROR_INVALID_MODE without releasing it, and uvc_stream_open_ctrl()'s failure path frees the stream handle without releasing it either — so any failed negotiation orphaned that interface.

Why

Both end with a USB interface bound to no driver at all.

For (1) the resubmission reaches usbfs on an interface the process no longer claims:

usb 5-1: usbfs: process 104350 (...) did not claim interface 0 before use

usbfs re-claims the interface on that path, evicting the driver that had just been reattached, and the following libusb_close() drops that claim without rebinding anything.

For (2) the interface stays claimed until libusb_close() drops the usbfs fd — which rebinds nothing either. The kernel says so directly: uvcvideo probes interface 0 while interface 1 is still held by usbfs and logs No streaming interface found for terminal 3, registering no video node.

Release order is load-bearing. Reattaching the driver to VideoControl is what makes uvcvideo probe the whole UVC function, and that probe claims the VideoStreaming interfaces itself — so VideoControl must be released last.

A natural A/B on one board shows this is device-class behaviour, not one camera. Same element, same binary, same failure mode; the only difference is the optional status endpoint:

	RØDE HDMI-to-USB-C 19f7:0080	DJI Osmo Pocket 3 2ca3:0023
VideoControl interrupt EP	none (bNumEndpoints=0)	ep_81, 16 ms
did not claim interface 0	absent	present
driver after close	uvcvideo / uvcvideo	uvcvideo / NONE
/dev/videoN restored	yes	no

Cameras with no status endpoint never submitted the transfer, so their teardown is byte-identical — which is why this looked model-specific.

How

• uvc_stop_status_xfer() cancels the transfer and waits, bounded (LIBUVC_STATUS_STOP_TIMEOUT_MS, default 500 ms), before any interface is touched. A new status_mutex makes the callback's stopping-check and its resubmission one critical section with the stop — without it the callback can read the flag as clear, lose the CPU, and still submit after the release. A drain that times out quarantines the handle exactly as a wedged stream already does, rather than freeing memory libusb still references.
• uvc_release_claimed_ifs() releases every interface in devh->claimed, VideoControl last.
• uvc_free_devh() no longer frees a transfer libusb still owns.

How to verify

cmake -S . -B build/regression -DCMAKE_POLICY_VERSION_MINIMUM=3.5 \
  -DCMAKE_BUILD_TYPE=Debug -DCMAKE_BUILD_TARGET=Static -DBUILD_SHARED_LIBS=OFF \
  -DBUILD_EXAMPLE=OFF -DBUILD_TEST=OFF -DBUILD_TESTING=ON
cmake --build build/regression --parallel
ctest --test-dir build/regression --output-on-failure   # 23/23

Four new libuvc.teardown.* cases --wrap the libusb entry points into an ordered operation log and drive the real uvc_close(). On the pre-fix code they print the defect verbatim:

 0  set_alt        iface=0
 1  submit         iface=-1
 2  release_if     iface=0
 3  submit         iface=-1     <- URB after the release
 4  attach_driver  iface=0
 5  submit         iface=-1     <- URB after the driver was reattached
 6  close          iface=-1     <- interface now bound to nothing

no_status_endpoint_unchanged is the negative control and passes both before and after.

On hardware (Rock 5B+, DJI Osmo Pocket 3, 5 consecutive open/close cycles):

	before	after
did not claim interface 0	6 / 6 cycles	0 / 5
driver after close	NONE / NONE	uvcvideo / uvcvideo every cycle
/dev/videoN restored	no	yes, every cycle

Risks

• The bounded drain adds at most LIBUVC_STATUS_STOP_TIMEOUT_MS (500 ms) to uvc_close(), and only for a device whose event thread is wedged — a cancellation normally lands within one endpoint interval (8–32 ms). Both bounds are overridable at compile time.
• status_mutex is taken only by the status callback and the stop; libusb_cancel_transfer() is asynchronous and never re-enters the callback, so there is no lock inversion.
• The quarantine path is unchanged in spirit: it still leaks rather than free memory a late callback can touch, and now covers the status transfer for the same reason.
• Devices with no VideoControl status endpoint are untouched, verified by the negative-control test and on hardware.

Deployment note: never leave a backup of the old shared object in the library search path — ldconfig scans every lib*.so* and links by SONAME, so a libuvc.so.0.0.7.bak sitting next to it will capture libuvc.so.0.