[Bug]: Desktop-linked environment never re-registers its port after restart; stale relay ingress when 3773 is taken

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. On the Windows desktop app, link the local environment to T3 Connect via the UI while the backend is on the default port 3773.
2. Make 3773 unavailable before the next start. Easy way on Windows with WSL networkingMode=mirrored: run t3 service install inside WSL (the service binds 127.0.0.1:3773, which is visible to Windows in mirrored mode). Any other listener on 3773 works too.
3. Restart the desktop app. It logs selected backend port via sequential scan with port: 3774.
4. Connect to this environment from another device through T3 Connect.

Expected behavior

After a restart the backend re-registers its current loopback origin with the relay, the same way CLI-linked servers do on startup (apps/server/src/server.ts, "T3 Connect desired link reconciled on startup"). Alternatively the desktop should keep using the port that was registered at link time and fail loudly if it cannot.

Actual behavior

The managed tunnel keeps the origin from link time. cloudflared /config on the Windows connector still shows "service":"http://127.0.0.1:3773" while the backend listens on 3774. Every relay request is forwarded to 3773; in my case that was the WSL t3 serve instance (a different environment id), which answers 401 (Invalid cloud health request). Connector metrics: cloudflared_tunnel_response_by_code{status_code="401"} 91, total_requests 92. Remote clients show:

T3 Connect · Reconnecting: Relay could not reach the environment endpoint (endpoint_request_failed).

The startup reconcile in server.ts is gated on CloudCliState.readCliDesiredCloudLink, which is only set by t3 connect link, so UI-linked desktop environments have no code path that updates the origin. The desktop also does not re-link on port change (apps/web/src/cloud/linkEnvironment.ts sends origin only at link time).

Related: #7458 (same symptom on the service update path), #6097 (desktop scanning past 3773 when a service is running).

Impact

Blocks work completely (remote access to the Windows environment is dead until the environment is unlinked and re-linked from the UI, or the port is pinned).

Version or commit

Desktop 0.0.42 (Windows), server 0.0.42. Verified against repo HEAD 52d08a14: apps/desktop/src/app/DesktopApp.ts:73-101 (scan), apps/server/src/server.ts:743-763 (CLI-only reconcile).

Environment

Windows 11 host, WSL2 Ubuntu with networkingMode=mirrored, t3 service install inside WSL. Remote client: macOS desktop 0.0.42.

Logs or stack traces

desktop.trace.ndjson:

"selected backend port via sequential scan" {"port":3774,"startPort":3773}

server.trace.ndjson (the server actually receiving the relay traffic):

environment.cloud.health Failure EnvironmentHttpUnauthorizedError: Invalid cloud health request.

Windows connector GET 127.0.0.1:20242/config:

{"hostname":"prod-….t3coderelay.com","service":"http://127.0.0.1:3773"}

Workaround

Set T3CODE_PORT=3773 as a user environment variable on Windows (the desktop honours it, DesktopConfig.ts:44) and move any other listener off 3773 (for the WSL service: systemd drop-in with Environment=T3CODE_PORT=3790, it re-registers on startup).

Read apps/desktop/src/app/DesktopApp.ts, apps/desktop/src/DesktopConfig.ts, apps/server/src/server.ts, and apps/web/src/cloud/linkEnvironment.ts; trace startup port selection and link reconciliation. Reproduce with WSL mirrored networking, then verify that after a restart the relay origin matches the selected backend port and remote requests reach the environment.