fix(antigravity): heal empty-projectId accounts via retryable auto-onboarding

[rqzbeh]

Summary

Accounts with an empty Google Cloud Code projectId fail every request
with 422 Missing Google projectId. The 3.8.50 bootstrap already tries to
auto-create the missing project via Google's onboardUser endpoint (then
re-discovers it via loadCodeAssist) — but a single failed attempt was
memoized forever in onboardAttemptedCache (a plain Set), so every later
request in the same process skipped onboarding and 422'd, even when a retry
would have succeeded.

This PR makes auto-onboarding retryable and self-healing:

• The permanent per-token memo is replaced with a failure-backoff map:
  a failed onboard attempt is retried once the 5-minute backoff expires, so a
  transient failure (network blip, upstream 5xx) no longer poisons the account
  for the process lifetime.
• The in-flight per-token lock still dedupes concurrent calls (one onboard
  attempt at a time per token).
• A successful discovery clears the failure marker and is memoized + persisted
  exactly as before (projectCache LRU, persistDiscoveredAntigravityProjectId).

Net effect: accounts that CAN be onboarded (have a refresh token) heal
automatically on a later request or token refresh — the Google project is
created without any user action. Accounts without a refresh token still
require a one-time OAuth re-auth (Google-side limitation, cannot be fixed in
code).

Related Issues

• Fixes the "empty google project id → error" report (production v3.8.49 log:
  422 Missing Google projectId ... loadCodeAssist found no Cloud Code project)

Validation

• Change type: routing
• Focused tests and category gates from the golden path
• npm run lint — no issues in changed files
• Reconciled with the current active release base (branch from release/v3.8.50 tip)
• Production-code changes include a new automated test in this PR
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Focused tests run:

node --import tsx/esm --import ./open-sse/utils/setupPolyfill.ts --test \
  tests/unit/antigravity-discovery-bootstrap.test.ts \
  tests/unit/antigravity-missing-project-chat.test.ts \
  tests/unit/token-refresh-service.test.ts          # 55/55 pass

Tests Added Or Updated

• tests/unit/antigravity-discovery-bootstrap.test.ts:
  • updated: "does not re-attempt onboardUser within the failure backoff
    window" (was: "does not retry onboardUser for the same token" — behavior
    within the window is unchanged, name now matches the backoff semantics)
  • added: "retries onboardUser after the failure backoff expires (account
    heals itself)" — first attempt fails, backoff blocks an immediate retry,
    after the backoff expires the account re-onboards and recovers the project

Coverage Notes

• Change is confined to open-sse/services/antigravityProjectBootstrap.ts
  (one cache data structure + its gate/finally bookkeeping) plus the test
  suite; no routing, executor, or wire-format behavior changes.
• clearAntigravityProjectCache (test export) now clears the failure map too;
  a new test-only clearAntigravityOnboardBackoff(key?) simulates backoff
  expiry.

Reviewer Notes

• ONBOARD_RETRY_BACKOFF_MS = 5 min bounds Google-side retry load: at most one
  onboard attempt per token per 5 minutes, plus the existing LRU cap
  (MAX_CACHE_SIZE = 256).
• Successes are memoized as before (LRU, no TTL — pre-existing behavior,
  unchanged); this PR only changes the FAILURE path.
• The geo-block issue for this deployment is handled by the separate PR
  (fix(antigravity): classify geo-blocked egress, exclude account, real connection probe #10420): accounts whose egress location is refused still 422/400 until
  egress is routed through a supported region — auto-onboarding cannot create a
  working project from a blocked region.

[diegosouzapw]

Thanks for this — the failure-backoff redesign in antigravityProjectBootstrap.ts is a real fix for a real problem (a single transient onboardUser failure permanently poisoning an account for the process lifetime), it's a clean, well-scoped change, and the new test coverage for the backoff/heal cycle is thorough. I ran the focused suite you listed plus token-refresh-service.test.ts and got 57/57 green, and all fast-path CI checks are passing.

Two things I'd like fixed before merge:

1. EditConnectionModal.tsx: the new isProjectIdManual flag doesn't actually get saved. It's set on updates.providerSpecificData right after the project-id field (line ~515), but for OAuth connections — which Antigravity always is — the code a bit further down (lines ~620-643) unconditionally rebuilds updates.providerSpecificData from connection.providerSpecificData before the request goes out, discarding the flag you just set. As shipped, the guard you added in tokenRefresh.ts (!credentials.providerSpecificData?.isProjectIdManual) is checking a field that's never actually persisted. Could you merge the flag into that later object (or set it after it) and add a regression test? There's a good template already in the repo for this exact surface: tests/unit/dashboard/edit-connection-modal-openai-store-toggle.test.tsx.

2. The #2934 citation for the "Google deprecated automatic project creation" claim points at an unrelated issue (it's a closed MCP-memory-auth feature request, not anything about GCP/Antigravity). Since the whole BYOP-detection heuristic — and its permanent, non-expiring cache — rests on that claim about Google's behavior, could you swap in the real source (a production log excerpt of the actual onboardUser response, or the correct tracking issue)?

One more thing worth a look, not blocking: returning 403 for the new BYOP fast-fail path routes it through chatCore's generic "401/403 → refresh credentials and retry" handling, so every request from an affected account triggers a real (and pointless, since refreshing the token can't create a GCP project) round trip to Google's OAuth token endpoint before the 403 reaches the client. I confirmed this by instrumenting your own BYOP test — the token endpoint is hit once per request, indefinitely (no backoff, unlike the onboard-failure path). Might be worth having chatCore skip the refresh-retry for this specific error code, or using a status it doesn't intercept.

Happy to take another look once these land.

[rqzbeh]

Thanks for the detailed review — all three points are addressed in commit 5a4bbcc2e (pushed, CI re-running):

1. isProjectIdManual now actually persists. The dead assignment (set on updates.providerSpecificData then unconditionally rebuilt by the OAuth path) is removed; the flag now lands in the single surviving antigravity merge block that runs after both the OAuth and API-key branches, so tokenRefresh.ts is guarding a field that really reaches the PUT. Added tests/unit/dashboard/edit-connection-modal-antigravity-project-manual.test.tsx (modeled on the OpenAI-store-toggle template you pointed at): it renders an OAuth antigravity connection, types a Project ID, saves, and asserts onSave receives providerSpecificData.isProjectIdManual === true — plus the empty-field case asserting false.

2. Citation swapped for the real source. All #2934 references (bootstrap doc comment + detection comment, executor comment, and the three test files' names/comments) now point at #8491 — the actual tracking issue for the empty-Google-projectId → 422 class, whose body carries the production log excerpt. The BYOP comment is also reworded to state the observable fact (onboardUser 200 without cloudaicompanionProject) rather than the unverifiable deprecation claim.

3. BYOP fast-fail no longer triggers the pointless refresh. The executor now returns 422 for GCP_PROJECT_REQUIRED instead of 403 — 422 is outside chatCore's 401/403 refresh-retry set, so an affected account no longer hits Google's OAuth token endpoint on every request, and it matches the sibling missing_project_id error the client already maps to an action-needed prompt. Both BYOP tests updated (executor fast-422s, and the chat-level test now asserts the 422 passthrough with the actionable message intact).

One note for transparency: the commit also carries an eslint-disable-next-line react-hooks/set-state-in-effect on the modal's pre-existing form-hydration effect — that error exists on release/v3.8.50 unchanged (verified), the dashboard isn't covered by the CI lint gate, and the repo already uses this exact convention in 11 other dashboard files, so I followed it rather than refactoring unrelated form logic in this PR.

Verified locally before pushing: 88/88 node:test (executor, missing-project-chat, discovery-bootstrap, token-refresh-service, streaming-sanitize), 5/5 vitest including the new regression test, typecheck:core clean, ts7 ratchet 0 added, eslint clean on all touched files.

[rqzbeh]

Follow-up on the "one more thing worth a look" note from this review (the 403 → 401/403 refresh-retry interaction): the account-rotation piece is now a separate PR — #10470 (feat(antigravity): auto-rotate BYOP accounts to siblings on GCP_PROJECT_REQUIRED).

Quick summary of the design decision: a gcp_project_required 422 is account-specific (that Google account lacks a GCP Project ID), so instead of just returning the error, routing now marks the connection excluded (24h, same rateLimitedUntil mechanism as the GEO_BLOCKED exclusion) and rotates to a sibling antigravity account within the same request — the actionable 422 surfaces only when no sibling exists. It's classified as its own error type (explicitly not MODEL_NOT_FOUND, so no model lockout), and the rotation state is tracked separately from maxAttempts so non-BYOP antigravity failures never get a second upstream shot.

It's stacked on this branch (the 422 fast-fail only exists here), so it reduces to its own delta once #10424 merges. This PR keeps the two review fixes as-is.