[Bug]: Misleading "Broken IPv6" network timeout error shown when Antigravity runtime hangs at startup #29039

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 an Intel Mac or an environment where agy_acp_server.par fails or hangs during startup (e.g. [Bug]: Antigravity won't install on Intel Macs — the runtime hangs at startup #16714).
2. Go to Settings -> Providers -> Antigravity.
3. Click "Sign in" (OAuth personal).
4. Wait 30 seconds.

Expected behavior

If the Antigravity child process has not emitted any stdout/JSON-RPC response or has hung during initialization, the UI should indicate that the provider process is unresponsive / timed out starting up, rather than diagnosing a network issue.

Actual behavior

T3 Code displays:
"Antigravity has not reached Google after 30 seconds. Check this machine's network connection. Broken IPv6 is a common cause."

This diagnostic is misleading when the issue has nothing to do with networking or IPv6, but rather that the local agy_acp_server.par subprocess hung before it could even begin the OAuth flow or emit a sign-in URL.

Impact

Blocks work completely

Version or commit

No response

Environment

macOS 15 (darwin-x86_64), T3 Code (Beta)

Logs or stack traces

Antigravity sign-in timed out waiting for authorization URL after 30000ms

Screenshots, recordings, or supporting files

No response

Workaround

Diagnosing the hang required manual process stack sampling (sample ) to find that the runtime was stuck in libffi before any network connection attempt was made.