Recover CDC interface number on macOS

[HeikkiRadu]

Summary

faultycmd info against a freshly-flashed FaultyCat on macOS skipped
every CDC port with could not determine its interface number. pyserial
on macOS surfaces a hwid + location shape that none of the existing
parsers fire on:

hwid='USB VID:PID=1209:FA17 SER=FLT3-E6633C805B3A3827 LOCATION=20-2'
location='20-2'

Two new fallbacks in usb._interface_from_port pick up the slack:

4. iInterface string match. pyserial may populate port.interface
   with the firmware's iInterface descriptor (set in
   usb/src/usb_descriptors.c: FaultyCat EMFI Control,
   FaultyCat Crowbar Control, FaultyCat Scanner Shell,
   FaultyCat Target UART). When present, a direct lookup recovers
   the role. Cross-platform — not macOS-specific, just hadn't been
   wired before.
5. Device-name trailing-digit parse. macOS encodes the data
   interface number as the trailing digit of /dev/cu.usbmodem<...><N>.
   For our 4-CDC composite the trailing digits are 1, 3, 5, 7 →
   control IFs 0, 2, 4, 6 → emfi, crowbar, scanner, target.
   Subtract 1 because the rest of the code uses control IFs (data =
   control + 1 per the CDC class spec).

The new fallbacks only run when the prior platform-specific parsers
return None, so Linux / Windows behaviour is unchanged.

Commits (2)

1. 6ad91b8 fix(host): recover CDC interface number on macOS
2. ae614d8 style(tests): apply ruff auto-fix on _macos_port hwid

Files changed

• host/faultycmd-py/src/faultycmd/usb.py — extended docstring +
  _INTERFACE_BY_STRING table + _MACOS_USBMODEM_RE + two new
  fallback branches in _interface_from_port.
• host/faultycmd-py/tests/test_usb.py — FakePort.interface field,
  _macos_port helper, two new fixtures (macos_environment +
  macos_with_iinterface_environment), 8 new test cases covering
  both fallback paths.

Reproduction (before this PR)

$ faultycmd info
found FaultyCat CDC at /dev/cu.usbmodem14201 but could not determine its interface number
  (hwid='USB VID:PID=1209:FA17 SER=FLT3-E6633C805B3A3827 LOCATION=20-2', location='20-2') — skipping
[ditto for ...14203, ...14205, ...14207]
No FaultyCat CDC found. Check that the board is plugged in and re-enumerated as 1209:fa17.

Test plan

• pytest host/faultycmd-py/tests/test_usb.py — 23/23 passing
  (was 15 before; +8 new macOS cases).
• pytest host/faultycmd-py/tests/ — 167/167 passing (no
  regression on the other 144 tests).
• ruff check host/faultycmd-py/src host/faultycmd-py/tests —
  clean. pre-commit run --all-files — all 12 hooks pass.
• On macOS: faultycmd info against a flashed board lists 4
  CDCs with their roles (emfi, crowbar, scanner, target-uart) and no
  skip warnings.
• On macOS: faultycmd emfi ping reaches the board and
  returns PONG.
• On macOS: faultycmd tui opens with the firmware version
  in the header subtitle and a working diag tail.
• Regression check on Linux: faultycmd info still
  enumerates ttyACM0..3 as before.

Notes for reviewers

• The fallback ordering is intentional: iInterface string is checked
  BEFORE the device-name parse, because it's the more robust signal
  (matches across any platform where pyserial populates the field,
  not just macOS).
• The _MACOS_USBMODEM_RE anchors on .usbmodem not on /dev/cu. so
  the same regex would also match a hypothetical /dev/tty.usbmodem*
  if a future macOS release switches the prefix.
• Verified on the reporter's MacBook with firmware vX.Y.Z.W from a
  draft release. The bug existed since v3 was first ported to macOS;
  this PR is what makes that port actually work in practice.