fix(antigravity): send complete loadCodeAssist metadata (ideType/platform/pluginType as numeric enums)

[rifqiawl]

Summary

loadCodeAssist and onboardUser both returned 403 for every account on a live
deployment, even accounts that had completed Gemini Code Assist onboarding.

Root cause

Traced via a live log side-by-side (same Google account, same host) against the
sibling 9router project, which succeeds against the identical account:

• OmniRoute — getAntigravityLoadCodeAssistMetadata() sent
  { ideType: "ANTIGRAVITY" }: ideType as a bare string, platform and
  pluginType omitted entirely.
• 9router — sends { ideType: 9, platform: <os/arch enum>, pluginType: 2 }.

The metadata body on this endpoint is protobuf-JSON-shaped: ideType/pluginType
are int32 enums on the wire, not strings, and platform is expected. An
incomplete/malformed client identity reads to Google's backend as untrusted and
gets rejected outright rather than degrading gracefully.

Fix

Mirror 9router's LOAD_CODE_ASSIST_METADATA enum values and platform-detection
logic (darwin/linux/win32 × x64/arm64) exactly:

const ANTIGRAVITY_IDE_TYPE_ENUM = 9;
const ANTIGRAVITY_PLUGIN_TYPE_GEMINI_ENUM = 2;
// DARWIN_AMD64:1, DARWIN_ARM64:2, LINUX_AMD64:3, LINUX_ARM64:4, WINDOWS_AMD64:5

A prior version of this function carried the opposite claim in a comment
("Matches Antigravity-Manager quota.rs: only ideType — no platform, LINUX is
rejected"). That may have been true when it was written; it directly
contradicts today's live comparison, where the full-enum shape (including a
Linux platform value) succeeded from a Linux host. Left a note pointing at
this history in the code in case it resurfaces — worth a second look if
anyone reports a regression specifically tied to Linux hosts.

Honest caveat

In the specific deployment where this was found, the actual 403 root cause
for that operator turned out to be unrelated: a custom
ANTIGRAVITY_OAUTH_CLIENT_ID override pointing at a GCP project without the
private Cloud Code API enabled (Google's OAuth-client-identity check fails
before the request body/metadata shape would ever matter). This metadata fix
did not resolve that particular deployment's error on its own. It's
included here anyway because it's a real, independently verified correctness
bug — confirmed by a byte-for-byte comparison against 9router's identical,
live-working request shape — that could still cause failures for any account
using OmniRoute's default embedded OAuth client (not a custom override).

Validation

• Updated tests/unit/antigravity-headers.test.ts's metadata-shape assertion
  (previously asserted the broken string-only shape as correct) — 6/6 passing.
• 54 usage-service + 25 oauth-provider tests whose assertions already compare
  live output against this function — all still passing (no hardcoded
  duplicate of the old shape anywhere else).
• npx tsc --noEmit -p tsconfig.typecheck-core.json: 0 errors.

I could not re-validate this specific fix against a live Google account
myself (no credentials here) — the live comparison that surfaced the bug was
done via the operator's production deployment logs, documented above.

⚠️ base-red inherited: #11874