[Bug]: Antigravity sign-in still does not open browser after #9425

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 / Antigravity provider authentication

Regression after #9425

The original Antigravity sign-in issue (#9405) was fixed by #9425. I installed a new Nightly containing that fix, but Google sign-in still does not open a browser or expose the sign-in link.

Environment

• OS: Windows 11 25H2
• T3 Code: 0.0.39-nightly.20260904.1276
• Installed managed runtime: agy_acp_server_20260818_01_RC01
• Browser: Vivaldi, registered as the default HTTP/HTTPS browser
• T3 server: local Windows environment

Steps to reproduce

1. Enable Antigravity in Settings > Providers.
2. Install the managed Antigravity runtime.
3. Click Sign in with Google.
4. Wait for the authentication flow.

Expected behavior

T3 opens the Google sign-in page, or displays Open sign-in page / Copy sign-in link so the URL can be opened manually.

Actual behavior

No browser opens and no sign-in link is shown. The provider remains stuck in sign-in progress and eventually returns to an unauthenticated/error state.

Diagnostics

The installed build contains the #9425 stderr-handling changes. During the latest attempt, the server trace recorded:

• ProviderAuthService.start: Success
• ws.rpc.provider.auth.start: Success
• antigravityAuthSupport.handleStderr: Success
• antigravityAuthSupport.handleStdoutLine: Success
• offerOutgoing: Success

Despite those events:

• No external browser launch is recorded in the desktop trace.
• No complete authentication URL is exposed in the server or desktop logs.
• RpcClient.authenticate ended as Interrupted after approximately 283 seconds.
• removeAntigravitySessionFiles then completed successfully.
• The provider cache reports status error, auth unauthenticated, and message: Antigravity sign-in or sign-out is in progress. Try again after it finishes.

The managed ACP process is present and the runtime installation itself succeeds. The failure appears to remain in the handoff from the Antigravity auth URL handler/outgoing event to the desktop provider UI and browser-opening/copy-link fallback.

Could this be investigated as a follow-up to #9405/#9425, particularly the desktop/client handling of the URL after it is forwarded from ACP stderr?

Start by reading #9425 and tracing the reported ProviderAuthService, antigravityAuthSupport, ws.rpc.provider.auth.start, and offerOutgoing events through the desktop authentication flow. Reproduce the Windows steps and compare the traces. Done means the Google URL reaches the desktop UI, opens the browser, or is available through an Open sign-in page or Copy sign-in link fallback.