File Bridge 1.16.0 — the panel names the reason the cable is dead

The panel now tells you why the cable is not working, instead of saying
something true and useless.

Server and Mac app only. The APK is unchanged from
v1.15.0 —
Android is still 1.13.0 (versionCode 16), attached here for convenience so the
newest release always carries a working one.

What happened

USB tethering was turned on, and it worked — on the phone. Unlike the adb
attempt, the device genuinely rebuilt its USB function set (idProduct
4221 → 4234) and published:

RNDIS Communications Control@0   239/4/1
RNDIS Ethernet Data@1             10/0/0

Android tethers over RNDIS. macOS has never shipped a driver for it —
/System/Library/Extensions holds AppleUSBECM.kext and AppleUSBNCM.kext,
for CDC ECM and NCM, and nothing else. Both interfaces matched only the generic
IOUSBHostInterface, zero network driver nodes bound, no enX appeared,
and tether_ip() correctly found nothing.

The phone believes it is tethering. The Mac cannot see it.

Why this is a code change and not just a note

Without it the Cable card said "No phone on the cable" — true, and enough to
send someone hunting a driver that does not exist. rndis_on_cable() separates
"a phone is tethering and this Mac cannot use it" from "nobody turned
tethering on", and the card now reads:

Tethering, but macOS cannot use it
The phone is sharing over RNDIS. macOS ships ECM and NCM drivers and never
shipped one for RNDIS, so no network interface appears. Turn tethering off
and use USB debugging instead, or stay on wifi.

Confirmed against real hardware: rndis_on_cable() → True in 23 ms.

Detected by node name rather than by descriptor, deliberately. The
authoritative query (ioreg -l -c IOUSBHostInterface) costs 350 ms and
5 MB; the names cost 25 ms. The names are safe to trust — they come from
the Linux kernel's f_rndis gadget, not from a vendor. It runs in the watch
thread and never in a request, because /api/status is polled every 2.5 s. That
thread now starts with or without adb, since a tethering phone is worth watching
for either way.

Where the cable stands

Both wired paths are complete, tested to the socket, and dead on the hardware
they were built against:

Path	Result
adb reverse	The phone never publishes an adb interface (255/66/1). MagicOS gate — USB debugging on, "Transfer files" selected, replugged, idProduct unchanged.
USB tethering	The phone publishes RNDIS. macOS has no driver.

HANDOFF.md now says so plainly, so nobody re-runs the exercise expecting a
different answer, and docs/ARCHITECTURE.md carries both dead ends with the
descriptor evidence and the commands to read it yourself. The code is waiting on
a phone that publishes adb, or one that tethers over NCM.

Wifi remains the working transport, and it is not a consolation prize: it moved
this project's own 6.3 MB APK at 17.34 MB/s, against a cable that negotiates
USB 2.0 High Speed in both modes.

Versions

Piece	Version
Server	1.15.0
Mac app	1.15.0
Android app	1.13.0 (versionCode 16) — unchanged