tunneld: Reach remote and federated tunnelds over the /connect bridge

[doronz88]

Builds on #1893: /connect exposed the tunnel over HTTP, but nothing in pymobiledevice3 consumed
it, so a remote tunneld was only reachable by writing your own websocket client. This makes the
client speak it, and makes a tunneld able to front other tunnelds over the same bridge.

What

Reach a remote tunneld (--tunnel UDID@HOST[:PORT]). TunneldConnectDialer is an
asyncio.open_connection-compatible dialer plugged into the seam RemoteServiceDiscoveryService
already exposes for the userspace tunnel, so there is no new call site: every device connection an
RSD opens is bridged through /connect. The caller is handed one end of a socket.socketpair
whose other end is pumped against the websocket, so consumers that reach for
writer.get_extra_info('socket') (ServiceConnection) keep working. Bridging is automatic when
the tunneld host is non-loopback, and bridge=True (the @ form on the CLI) forces it for
addresses that only look local, such as an SSH port-forward.

Front several hosts with one tunneld (--upstream, repeatable). Federation previously only
merged an upstream's listing, and the addresses in that listing are ULAs on the upstream host's
utun — reachable only from a client that already had L3 connectivity to that host. So it
presupposed a VPN or hand-rolled routes, and a device discovered through an aggregator was a dead
end. A /connect for a device the instance does not serve itself is now relayed to the upstream
that owns it:

# every host with devices attached
sudo pymobiledevice3 remote tunneld --host 0.0.0.0

# the one host clients can reach (monitors off: it federates rather than competing for devices)
sudo pymobiledevice3 remote tunneld --host 0.0.0.0 \
    --no-usb --no-wifi --no-usbmux --no-mobdev2 \
    --upstream http://lab-1:49151 --upstream http://lab-2:49151

# from anywhere
pymobiledevice3 developer dvt ls / --tunnel 'UDID@front:49151'

GET / entries now carry an origin — null when served directly, else the URL of the hop that
reported them — so a client that can reach that upstream may skip the relay. Upstream close codes
are passed through, so a 4404/4502 names the tunneld that actually refused.

Remove --uds. It only ever moved the HTTP control channel onto a unix socket while the data
plane (the RSD dials, and now the bridge) always relied on TCP, so it never delivered a pure-unix
path. TunneldAddress narrows to (host, port); a --tunnel value with a non-numeric :suffix
now fails with a message naming the removal instead of being read as a socket path.

Bugs found and fixed along the way

• Federation cycles dropped the listings they were meant to merge. Tunnelds registering each
  other recursed on every GET /: the nesting spawned a growing tree of in-flight requests against
  the bounded to_thread executor, and the innermost fetches lost the race against their parents'
  2s timeout. With two mutually registered tunnelds, each one's listing was missing the other's
  device. Requests now carry a hop budget (x-tunneld-hops-remaining, 4), and a tunnel reported
  through several paths is listed once.
• /connect addressed a device, not a tunnel. A device can have more than one tunnel — a front
  tunneld that also monitors the same host holds its own alongside the federated one. Keying on
  the UDID alone paired whichever tunnel was found locally with the port the caller asked for,
  dialing an endpoint that exists nowhere (4502 failed to connect to [fdc9:…]:63727). /connect
  now takes an optional ?address=; older tunnelds ignore it and keep their UDID-only behaviour.
• Upstream URLs failed silently. A schemeless lab-1:49151 parses as scheme lab-1 with no
  host, so the listing fetch threw InvalidSchema into a debug log and the relay refused —
  registering one did nothing at all. https:// fetched over TLS but relayed in plaintext to port
  80. Registration now normalizes HOST, HOST:PORT and http://HOST[:PORT] to one canonical
  form and rejects what neither path could act on, as a usage error on --upstream and a 400 from
  POST /upstream.
• Abandoned bridges spewed teardown errors. Ctrl+C on a live stream (syslog live) left the
  pump coroutines to GC, which closes them with GeneratorExit, where the awaits in their finally
  blocks raised coroutine ignored GeneratorExit. Teardown is synchronous now.

Verification

Against a real iPhone (iOS 26.6.1) over USB, not only fakes:

• dvt ls / and dvt device-information through the bridge (--tunnel UDID@127.0.0.1, and the
  empty-UDID @host form), with zero tracebacks in the tunneld log.
• The same commands through an aggregator holding no tunnels of its own while fronting a
  separate tunneld process — a topology that is self-proving, since it has no other way to reach
  the device.
• The ?address= fix in the failing topology: an aggregator holding both its own tunnel and a
  federated one to the same device now serves dvt ls / over either, where both previously failed.

Automated: 704 tests pass (pytest -m "not device"), including new suites for the bridge
(tests/test_tunneld_remote_bridge.py) and federation (tests/test_tunneld_federation.py) that
spin up real tunneld servers over uvicorn/wsproto against a TCP echo server. The cycle and
?address= regressions were both confirmed to fail before their fixes. pyright --venvpath .
(1.1.411) reports 0 errors; ruff check / ruff format --check (0.15.4) and markdownlint are clean.

Notes

• /connect remains unauthenticated like the rest of the tunneld API, and an aggregator relays
  into other hosts' devices, which widens that exposure. The auth work offered in tunneld: Add /connect websocket endpoint exposing the tunnel over HTTP #1893 should
  land before this topology is advertised broadly; the docs carry the warning meanwhile.
• Relaying costs an extra hop through the front instance's event loop — negligible for control
  traffic, measurable on bulk transfers such as DDI mounts.
• Unrelated observation from tunneld: Add /connect websocket endpoint exposing the tunnel over HTTP #1893's test suite: on macOS, connecting to a socket held bound but
  not listening gets silence rather than an RST, so test_connect_tcp_connection_refused burns the
  full ~7.8s connect timeout on every run there.