Fix intermittent "Cannot find footswitch" on macOS

[titan550]

Human Note

I kept getting this error randomly even when the USB pedal was plugged in.

❯ ./footswitch -r
Cannot find footswitch with one of the supported VID:PID.
Check that the device is connected and that you have the correct permissions to access it. [init(), src/footswitch.c:111]

This patch fixed the issue for me.

Problem

On macOS, footswitch intermittently fails with:

Cannot find footswitch with one of the supported VID:PID.

even though the device is connected and visible to the system (ioreg /
hidutil both show it). A reboot "fixes" it for a while, then it comes back.

Root cause

The macOS branch of init_pid() opened the device with
hid_open(vid, pid, NULL), which opens whichever HID interface hidapi
enumerates first. The pedal is a composite device:

• interface 0 — keyboard/mouse, which macOS refuses to let an
  unprivileged process open (IOHIDDeviceOpen returns kIOReturnNotPermitted,
  0xE00002E2)
• interface 1 — the vendor interface that carries the config protocol

hidapi's macOS enumeration order isn't stable, so when interface 0 came
first, hid_open() tried it, was denied, and returned NULL → "Cannot find
footswitch". A reboot just reshuffled the order, which is why the failure
seemed to come and go.

Fix

Use the interface_number == 1 selection that the non-OSX path already used,
for all platforms. A macOS-only fallback to the previous
hid_open(vid, pid, NULL) is kept for older hidapi (<0.14) that doesn't
report interface_number on macOS, so existing setups are unaffected.

Testing

• macOS 26.4.1 (arm64), hidapi 0.15.0 (Homebrew): footswitch -r now reads
  reliably, including across unplug/replug cycles that previously triggered
  the failure.
• Builds clean (make, -Wall).
• Linux path is unchanged: the fallback is #ifdef OSX, and the libusb
  backend has always reported interface_number.

Notes

scythe.c, scythe2.c, and footswitch1p.c use the same bare hid_open()
pattern and likely share this latent issue on composite devices (possibly
related to #60). Left out to keep this PR focused — happy to follow up.

[rgerganov]

I am not able to this on a MacOS device at the moment but the root cause analysis sounds reasonable and the patch looks good.