[Bug]: Windows desktop stays headless when backend becomes ready after 60-second startup deadline

[ElliotDrel]

Summary

On Windows, the desktop app can remain headless when its backend needs slightly more than the fixed 60-second readiness budget. The backend later becomes healthy and listens on 127.0.0.1:3773, but the desktop process has already abandoned main-window creation.

Environment

• T3 Code Nightly 0.0.32-nightly.20260804.993
• Windows 11 Pro, build 26200, x64
• Local providers were already healthy and authenticated; this is not a missing-CLI/PATH failure.

Evidence

The desktop child log contains four separate failures over three days:

2026-08-03T01:56:29Z Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment
2026-08-03T16:02:08Z Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment
2026-08-04T01:26:51Z Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment
2026-08-04T21:22:01Z Timed out after 60000ms waiting for desktop backend readiness at http://127.0.0.1:3773/.well-known/t3/environment

For the latest failed launch:

• Desktop process began at 17:19:43 local time.
• Backend child began at 17:21:01.
• The desktop readiness wait failed at 17:22:01 after 60,042 ms, with repeated ECONNREFUSED 127.0.0.1:3773.
• Server tracing first appeared only around 17:21:57, then server.startup.ready.publish occurred at 17:22:27, 26 seconds after the desktop deadline.
• The resulting Electron processes were responsive, and the backend eventually listened on port 3773, but no BrowserWindow existed (MainWindowHandle = 0).

A forced restart immediately afterward succeeded:

• desktop readiness: 10,492 ms
• main window created about 21 seconds after process launch

This makes the failure intermittent/cold-start-sensitive rather than a permanent bad configuration.

Expected behavior

A late backend should not leave a responsive, headless desktop process indefinitely. Once the backend becomes ready, the main window should still be created, or the user should see a visible startup/error state with a retry action.

Suggested direction

1. Start the minimal HTTP readiness endpoint before expensive server initialization/discovery where possible.
2. Add timing around the uninstrumented period before the server's first trace event.
3. Do not treat the 60-second readiness deadline as terminal for window creation. Continue retrying with backoff, and create the main window if the backend becomes ready later.
4. If startup stays slow, show a startup window/status rather than leaving a background-only process.

I can provide sanitized trace excerpts if useful.