fix(ai): antigravity WIRE_COMPLETE_MODELS is a static snapshot of a live upstream catalog — the next wire-complete model silently 404s again (#1704 recurrence)

Evidence (verified 2026-11-05 on main d91f5a4, the merge of PR #1716)

PR #1716 fixed #1704 by teaching resolveModelAndEffort not to append an effort suffix to wire-complete model ids. The classification is a hardcoded set:

• packages/ai/src/protocols/antigravity.ts:82-92 — WIRE_COMPLETE_MODELS holds exactly 9 ids (gemini-2.5-flash, gemini-2.5-flash-lite, gemini-2.5-flash-thinking, gemini-2.5-pro, gemini-3-flash, gemini-3.1-flash-image, gemini-3.1-flash-lite, gemini-3.5-flash-lite, gemini-3.8-flash-tiered).
• packages/ai/src/protocols/antigravity.ts:101 — every other model id gets -<effort> appended: WIRE_COMPLETE_MODELS.has(model) ? model : \${model}-${resolved}``.
• The set was transcribed from a one-time live probe of the upstream v1internal:fetchAvailableModels catalog (26 keys, daily- and prod cloudcode-pa, 2026-11-05) — that catalog exists in this repo only as a comment (antigravity.ts:62-81) and in PR fix(ai): send wire-complete antigravity model ids bare, not effort-suffixed (#1704) #1716's commit message. grep -rn fetchAvailableModels packages/ai/src returns only the comment: the provider never fetches or validates against the catalog at runtime.
• packages/ai/test/provider/antigravity.test.ts:114-149 pins the behavior by example (4 of the 9 set members, plus suffix-healing) but no test or fixture asserts the set against the probed catalog, so nothing fails when the set and the catalog drift apart.

Why it matters

The upstream catalog is live and changes (models are added/renamed by Google, not by this repo). The first time a user selects a wire-complete model that shipped upstream after 2026-11-05 — or a renamed one — resolveModelAndEffort appends -medium (or the chosen effort), minting an entity that does not exist upstream, and streamGenerateContent answers 404 NOT_FOUND. That is exactly the #1704 failure mode ("provider down for plain prompts"), recurring silently with no test, gate, or probe positioned to catch it before a user does. The effort-family side has the symmetric risk: an effort family upstream starts keying bare would be suffixed into a 404 the same way.

Acceptance criteria

• The wire-complete classification is checked against a recorded catalog fixture: a test in packages/ai/test/provider/antigravity.test.ts (or a sibling) holds the probed 26-key catalog (both endpoints, dated) as data and asserts every key is classified correctly — bare keys resolve bare, effort-family keys resolve to a catalog key — so a set edit without a catalog re-probe fails loudly.
• A documented refresh path exists (script or probe note in the fixture header): how to re-probe fetchAvailableModels on daily- and prod cloudcode-pa and update the fixture + set together.
• OR, instead of the fixture: classification is derived at runtime from a fetchAvailableModels call where auth is available, with the static set kept only as an offline fallback — and a test covers the fallback classification against the fixture.
• Existing antigravity tests stay green (bun test test/provider/antigravity.test.ts in packages/ai), including the suffix-healing cases from PR fix(ai): send wire-complete antigravity model ids bare, not effort-suffixed (#1704) #1716.

Filed by new-issue-creator-opencode, 2026-11-05 run (verified by reading the code at main d91f5a4 in a laptop worktree; all 6 root check:* gates green at that SHA). Related: #1704 (the bug this classification fixed), PR #1716.