Make ios list discover tunnel/RSD-backed devices

[danielpaulus]

Is your feature request related to a problem? Please describe.

ios list currently appears to be tied to local usbmuxd-style device discovery. That means it returns no devices on a Mac that has a reachable iOS 17+ RSD/userspace tunnel but no locally attached usbmuxd device.

Concrete repro from a remote-device bridge setup:

• office01 has the real paired iPhone locally and runs go-ios userspace tunnel.
• The tunnel agent exposes the device at:
  • UDID: 00008120-001905DE2E9B401E
  • address: fd6f:7edb:be57::1
  • RSD port: 62173
  • userspace tunnel forwarded locally as 127.0.0.1:61246
• From another Mac, the tunnel itself is reachable and Xcode/CoreDevice can discover a bridged RemotePairing device.
• But go-ios CLI discovery still reports no local devices:

go run . list --udid=00008120-001905DE2E9B401E --address=fd6f:7edb:be57::1 --rsd-port=62173 --userspace-port=61246 --details --pretty

Observed output:

{
  "deviceList": []
}

And commands such as rsd ls/info fail early with variants of:

Device not found: 00008120-001905DE2E9B401E
Device '00008120-001905DE2E9B401E' not found. Is it attached to the machine?

This makes the CLI unusable from a host that can reach an iOS 17+ RSD tunnel but does not have the device in local usbmuxd discovery.

Describe the solution you'd like

Make ios list and device resolution understand non-usbmuxd tunnel-backed devices.

Desired behavior:

• ios list should include devices known from a configured/running go-ios tunnel agent (/tunnels) even when usbmuxd has no local attachment.
• Commands should support an explicit hard target using --address, --rsd-port, and optionally --userspace-port, without first requiring the device to resolve through usbmuxd.
• When --udid is provided together with explicit tunnel coordinates, use the UDID as identity metadata/filtering, not as a reason to fail if usbmuxd does not know the device.
• The output should make the transport clear, e.g. connectionType: userspaceTunnel or similar.

Implementation shape that would fit the current architecture:

• Introduce a device resolver source for RSD/tunnel devices alongside usbmuxd.
• Query the go-ios tunnel agent (/tunnels) when available and merge those entries into list output.
• Add a direct RSD target path for commands where --address --rsd-port are supplied.
• For userspace tunnel forwarding, preserve --userspace-port as the local forward endpoint for service connections.

Describe alternatives you've considered

• Keep relying on usbmuxd discovery and require commands to be run only on the physical host. This blocks remote workflows and makes userspace tunnel forwarding less useful.
• Add separate specialist commands for RSD-only devices. That would work, but users would still expect ios list and normal command resolution to show reachable devices.
• Let higher-level bridges emulate usbmuxd. That is heavier and duplicates logic that go-ios already has for RSD and userspace tunnels.

Additional context

This came up while building/testing a RemotePairing/CoreDevice bridge for iOS 17+ devices. Xcode/CoreDevice can see and use the bridged device over RemotePairing Bonjour, but local go-ios CLI commands still do not list it because they appear to start from usbmuxd/local-device discovery.

The feature would also make go-ios more robust for cloud/office tunnel setups where the device is physically attached to another host but its RSD/userspace tunnel is reachable locally.