XR clients never find server when server device has Tailscale enabled

[j5155]

Describe the bug
When using XR mode on a server with Tailscale running, on robot wifi without internet access, the clients never find the server as long as Tailscale is active. As soon as Tailscale is stopped and the qr code is regenerated, the problem is immediately resolved. Probably the wrong IP is being reported in the QR code (Tailscale's 100.x.x.x ip instead of the local 192.168.43.x ip)
This isn't high priority or a massive blocker for anything, since toggling Tailscale isn't particularly hard, it's just annoying to remember to turn off and back on.

To Reproduce
Steps to reproduce the behavior:

1. Install AdvantageScope and Tailscale on the same device.
2. Activate Tailscale and AdvantageScope XR mode with the device on a LAN network as the client. I was specifically using an FTC robot's internal network and using data provided over FTC dashboard, but this is probably unnecessary; any situation where both devices aren't using tailscale, or where the network does not provide internet, should recreate this scenario.
3. Notice how the device is stuck on searching for server and never finds it.
4. Disable tailscale and regenerate the QR code
5. Notice how the device immediately finds the server.

Expected behavior
XR mode should always work

Screenshots
If applicable, add screenshots to help explain your problem.

Version (required):
26.0.0-beta-1 and 26.0.0-beta-2, but probably version independent

Additional context
Add any other context about the problem here.

[blaze-developer]

Is the mobile device that you are connecting to the XR server with on the same tailnet? Connecting to any local server, not even specifically XR, requires that you have access to the same network. Activating a VPN like tailscale effectively moves your server into a different network. If your client device is not on the same network, connection cannot be achieved.

[j5155]

The mobile device's Tailscale status does not affect the behavior. This is taking place on a LAN only (robot provided) network where Tailscale isn't going to be able to establish a connection.
Tailscale, without exit nodes enabled, still allows for LAN access. It just adds a second interface. It does not tunnel all traffic.

[blaze-developer]

Perhaps you could check this behavior by setting up a similar condition with two computers, and seeing if one can ping the other.

I may be incorrect, but from my understanding, if Tailscale's behavior is blocking networking to the server device, there isn't much AdvantageScope can do.

[j5155]

The device can access the robot through the network. Tailscale isn't blocking any connections...
I'll try pinging the next opportunity I have.

I looked at the backend code and the QR code data and there's no obvious reason for this to fail. It has support for multiple IPs. Possibly it should give up trying earlier?

Notably it still works fine with tailscale off but docker networking on, even though docker networking is also providing an IP to the server that is being broadcast in the QR code. This might be because the docker ip itself has a bigger leading number, so it's sorted later in the list. In that case it would be nice to output 10.x and 192.x first in the list, plus whichever the SystemCore network will use, in the absence of a more reliable solution.

If my hypothesis is correct this could happen in any scenario where the server has an IP on a secondary interface with a number below the local one. In that case it might be much easier to reproduce (on Linux at least) by adding a dummy interface; I'll investigate that possibility soon too.