File Bridge 1.17.0 — the key stops leaking into the log, and tethering is finalised

Closes out the wired work. Contains a security fix that predates all of it
and matters whether or not you care about the cable.

The access key was being written into gui.log

log_message logged self.path verbatim, and every phone request carries
?t=<key>. So the live access key sat 758 times in a mode 644
~/.filebridge/gui.log, while ~/.filebridge/key holds the identical secret at
mode 600. Same secret, a fifth of the protection — in the file every note in
this repo calls "the first place to look", and the file someone pastes when
asking for help.

• Request lines now read t=<key>.
• The launcher chmod 600s the log on every launch, so logs written by older
  versions get tightened too.
• One hide_key() redacts both the request log and the am start output.

The lookbehind in it is load-bearing: a bare t= also occurs inside act= and
dat=, which am prints, and blanking those destroys the diagnostic it was
added to capture.

A gui.log written before this release has your key in it in the clear. It
is re-chmodded on the next launch, but delete it if it was ever shared.

Tethering is finalised

It is the wired path to reach for first, because it asks nothing of Developer
options.

--tether-net makes it testable for real. It was the least-verified thing here
for a bad reason: exercising it needed a sed on TETHER_NET in the source
plus a copy of tools/ beside the temporary file. Point the flag at a subnet
this Mac is already on and the whole path runs properly — detection, the
tether status block, all three QR variants decoded to three different hosts,
and the security gate that has to treat a caller on that subnet as a phone
rather than as this machine (200 for /api/list?t=, 403 for /api/status
and /connect).

The startup banner prints the tethered link, and stops implying one claim covers
both cable paths — a VPN cannot swallow loopback, it can absolutely swallow a
tethered address. The RNDIS message names what would work rather than only
what does not.

Where the cable actually stands

Both paths are code complete, tested to the socket, and neither works on the
hardware they were built against. HANDOFF.md records what would unblock each,
so nobody re-derives it:

Path	Blocked by	What would unblock it
Tethering	macOS has no RNDIS driver, and never has	a phone that tethers over CDC ECM or NCM
adb reverse	the phone never publishes the adb interface (255/66/1)	USB debugging that actually re-enumerates — then find out why am start refused, which 1.17.0 now logs

adb is parked, not abandoned: it was seen working once, tunnel and all, so
the transport is sound and only the launch shortcut failed.

Wifi remains the working transport and 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.

Versions

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

Debug-signed. Installs and upgrades in place, not Play Store distributable.