feat: route Antigravity provider models

[nuchareviews-beep]

Summary

Adds the locally registered antigravity provider — a bridge to the local agy CLI via bb-plugin-antigravity-acp — to Autorouter's routable-provider set. OmniRoute is deliberately excluded: this installation reserves it for delegated subagent work rather than interactive Autorouter threads.

What actually happens in practice — read this before merging

Antigravity/Gemini models have no entry in the compiled CursorBench table (benchmarks.ts), and this PR does not add one — there's no public benchmark data for them to draw from, and fabricating a score would be worse than not scoring them at all. That means:

• Antigravity becomes eligible for thread creation and is included in candidate discovery.
• It is not competitively ranked against Codex/Claude/Cursor under normal difficulty-based routing — it will not be chosen just because a task looks like a good fit for it.
• It is only actually selected via fallbackSelection, which runs when Codex, Claude Code, and Cursor are all simultaneously unavailable or quota-exhausted. That's a narrow, mostly-last-resort condition, not "Antigravity is now a normal routing option."

A real bug this PR originally had, found and fixed before merge

The first version of this PR added antigravity to router.ts's isRoutableProvider() set but missed that benchmarks.ts's rankAutoModelOptions() hardcoded its own separate copy of the same provider allowlist. That meant Antigravity was eligible for candidate discovery but silently excluded from ranking regardless — i.e., the PR as originally written would never actually route to Antigravity under any circumstance, not even the fallback case described above.

I caught this by actually running bb autorouter route live against a real bb instance instead of trusting the unit test suite alone — four real calls (low difficulty, high difficulty, an explicit "route this to agy" instruction, and a prompt naming a real agy model id directly) all still picked Codex every time. Fixed by unifying both files onto one shared ROUTABLE_PROVIDER_IDS (now living in benchmarks.ts), so this class of two-lists-silently-drift-apart bug can't recur.

Verification

• npm run test — 30 passing (28 existing + 2 new: one confirming Antigravity still correctly gets no fabricated benchmark score, one confirming fallbackSelection actually returns a route on it when it's the only eligible candidate)
• npm run typecheck, npm run build — clean
• Live-tested against a running bb instance before and after the fix, not just the unit suite (see above)
• Confirmed no regression: normal-case routing (difficulty 1 and 97, both with Codex quota available) still correctly picks Codex, unchanged by this fix

Scope

• README.md — documents the provider boundary (and, honestly, its real limitation)
• router.test.ts, benchmarks.ts — the actual fix plus two regression tests

This is deliberately just the plain "make Antigravity a real, working eligible provider" change — no opinionated routing-priority policy included, to keep this focused and easy to review on its own.

[nuchareviews-beep]

Superseded by #2, which includes everything from this PR plus a full configurable routing-policy system (per-difficulty model selection with a configurable comparator, and a merged decision-agent/fallback-order picker) built on top of it.