Proposal: route Antigravity OAuth URL through a sign-in-only loopback sink on Windows

[PabloValencia14]

Related bug: #9624. This revisits the mechanism from closed PR #9550 and credits its original implementation, but corrects the diagnosis.

Reproduction

On Windows 11 with nightly 0.0.39-nightly.20260904.1276 and the packaged Antigravity ACP:

• Invoking T3's current Node helper directly emits __T3_ANTIGRAVITY_AUTH_URL__ as expected.
• Invoking the exact same helper through Python webbrowser preserves all four parsed arguments and returns True, but the marker does not reach the parent stderr pipe.
• In the real T3 flow, authenticate then waits until cancellation/timeout and the desktop never receives an openExternal request.
• A sign-in-only Node preload posting the URL to a tokenized listener on 127.0.0.1 delivers it successfully through the same Python launch path.

This indicates that the remaining problem after #9425 is not late subscription replay, nor the default browser, nor Python treating the whole BROWSER value as one executable. The fragile boundary is the browser grandchild's stderr propagation on Windows.

Proposed scoped fix

Adapt the implementation from #9550:

1. Only for an ACP launch with onAuthorizationUrl, set BROWSER to the T3 runtime and preload a small CommonJS file through NODE_OPTIONS.
2. The preload reconstructs the HTTPS argument and POSTs it to a per-sign-in listener bound to 127.0.0.1 on an ephemeral port with a random path token.
3. The listener applies a strict body-size cap and passes the result into the existing receiveAuthorizationUrl path, which validates the Google origin, callback URI, and state before publishing it.
4. Normal ACP sessions inherit neither the preload nor the sink variable, so turn subprocesses are unchanged.

I have a current-main branch with the original #9550 authorship preserved, comments corrected to match the reproduction, git diff --check clean, and an isolated end-to-end probe showing current path = no marker, loopback path = URL received. The repository dependency install is incomplete on this machine, so I have not claimed a fresh focused-suite run.

Would maintainers accept a fresh PR using this approach, or prefer a different transport for the authorization URL?