[Bug]: `t3 serve --tailscale-serve` prints a localhost pairing URL/QR code even when Serve is configured#25348

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On Linux, make sure the user can configure Tailscale Serve (sudo tailscale set --operator=$USER), with MagicDNS and HTTPS certificates enabled on the tailnet.
2. Run t3 serve --tailscale-serve.
3. Look at the pairing URL / QR code printed at startup.

Expected behavior

When --tailscale-serve is passed and Serve gets configured, the startup pairing URL and QR code point at the Serve endpoint (https://<machine>.<tailnet>.ts.net/pair#token=...), so another device can scan the QR code and pair.

If the startup link is meant to be loopback only, it should at least say so and point to t3 pair --tailscale.

Actual behavior

The pairing URL and QR code are printed with http://localhost:3773/... before the Tailscale Serve configured log line. The QR code is useless on any other device, which is the reason you'd pass --tailscale-serve in the first place.

Serve itself works. Afterwards tailscale serve status shows https://<machine>.<tailnet>.ts.net (tailnet only) |-- / proxy http://127.0.0.1:3773, and the HTTPS URL responds with 200. My guess is the link gets built before ensureTailscaleServe resolves, or it never uses the Serve URL.

Workaround: run t3 pair --tailscale once the server is up, or swap the host in the printed link by hand.

Related: #16238 (if Serve fails, the server silently stays loopback-only). That's a separate problem: here Serve succeeds, but the link printed at startup ignores it.

Impact

Minor: the first-run pairing flow doesn't work, but there's a workaround

Version or commit

t3 v0.1.2

Environment

Ubuntu 26.04.1 LTS, Linux 7.0.0-34-generic, tailscale 1.102.3 (snap, 1/stable)

Logs or stack traces