[Bug]: T3 Connect treats a spawned but unreachable tunnel as 'running'

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 macOS 26.5.2, connect the host to two active networks:
   • USB Ethernet is the default route and permits ordinary HTTPS, but blocks outbound TCP/UDP port 7844.
   • Wi-Fi permits outbound port 7844.
2. Enable T3 Connect in the desktop app.
3. Confirm the local environment is healthy:

   curl -i http://127.0.0.1:3773/.well-known/t3/environment

response line should be a HTTP/1.1 200 OK

4. Confirm the route-specific behavior against a documented Cloudflare Tunnel edge address:

   nc -b en6 -G 3 -vz 198.41.192.107 7844
   # Operation timed out
   
   nc -b en0 -G 3 -vz 198.41.192.107 7844
   # succeeded
   

5. Observe that the managed cloudflared child remains alive with a TCP connection stuck in SYN_SENT on port 7844; no Registered tunnel connection event occurs.

6. Run the T3 Connect status path and attempt to open the linked environment from a remote client. (Android)

Expected behavior

T3 Code should distinguish “relay client process spawned” from “managed tunnel connected.” Until cloudflared reports a registered tunnel connection, status and user-facing errors should not report or imply that the connector is ready. When registration repeatedly fails, the diagnostic should preserve enough of cloudflared's warning output to direct the user toward blocked Cloudflare Tunnel egress.

Actual behavior

The server returns status: "running" immediately after spawning cloudflared, before observing a registered tunnel connection. The Android app later reports only:

Failed to connect. Reason: relay environment is unavailable

There is no user-facing indication that the connector has never registered or that Cloudflare Tunnel egress is blocked.

Relevant current-main behavior:

• apps/server/src/cloud/ManagedEndpointRuntime.ts returns running based on child-process liveness and immediately after spawn.
• The same module already classifies Registered tunnel connection and warning output, but the observed readiness is not reflected in runtime status.

Impact

Major degradation or frequent failure

Version or commit

Desktop Alpha 0.0.33

Environment

macOS 26.5.2 (concurrent Wi-Fi and USB Ethernet conn), T3 Code Android

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

• Disable/unplug the filtered Ethernet interface or move Wi-Fi above it in network service order, then restart T3 Code.
• Alternatively, allow outbound TCP and UDP port 7844 on the default network.

Start in apps/server/src/cloud/ManagedEndpointRuntime.ts and trace the status path after cloudflared is spawned, alongside its existing handling of “Registered tunnel connection” and warning output. Reproduce the unreachable-port case with the documented nc commands and inspect the server status response. Done means an unregistered tunnel is not reported as ready and repeated registration failures preserve actionable egress diagnostics.