feat: Antigravity provider + configurable routing policy (difficulty bands, decision agent, fallback chains)

[nuchareviews-beep]

Summary

Supersedes #1. Includes everything from that PR (the antigravity provider becoming a real, working routable provider, plus the two-lists-drift-apart benchmark bug fix it caught and fixed) and a full configurable routing-policy system built on top of it — every routing decision that PR deliberately left as a fixed rule (to keep that PR focused) is now a plain, editable setting instead of logic baked into router.ts.

What's in this PR

1. Antigravity as a real routable provider (from #1, unchanged)

• Adds the locally-registered antigravity provider (bridges to the local agy CLI via bb-plugin-antigravity-acp) to Autorouter's routable-provider set.
• Fixes a real bug caught by live-testing, not just the unit suite: router.ts and benchmarks.ts each hardcoded their own separate provider allowlist, so Antigravity was eligible for candidate discovery but silently excluded from rankAutoModelOptions's ranking regardless. Both files now read one shared ROUTABLE_PROVIDER_IDS.
• OmniRoute stays deliberately excluded — reserved for delegated subagent work, not interactive Autorouter threads.
• Antigravity has no CursorBench entry (no fabricated score), so under plain benchmark ranking it's still only chosen via fallbackSelection when Codex/Claude Code/Cursor are all unavailable — unless a difficulty band below routes to it directly.

2. Per-difficulty model selection: native two-sided ranges (new)

settings.difficultyBands: an ordered list of { minDifficulty, maxDifficulty, fallbackChain } bands, checked low-to-high by effective lower bound. Both bounds are inclusive and independently nullable — minDifficulty: null means unbounded below (matches down to 0), maxDifficulty: null means unbounded above (matches up to 100), and minDifficulty === maxDifficulty matches an exact score. The first band whose range covers a task's difficulty score skips benchmark ranking entirely and routes straight through that band's own fallback chain.

This is a genuine two-sided range, not a series of independent one-sided thresholds paired up by hand: 0–25 for one model, 26–75 for another, 76–100 for a third, with no gaps or overlaps to manage. Chain entries can be a bare provider (any/default model) or an exact provider/model pin.

This directly replaces what would otherwise have been a hardcoded rule (SIMPLE_TASK_DIFFICULTY_MAX = 25 / SIMPLE_TASK_PROVIDER_PRIORITY = [antigravity, codex, claude-code]) — that logic doesn't exist in router.ts at all; it's only the default value of this setting. Add, remove, reorder, or clear bands freely from the settings page or:

bb autorouter config --difficulty-bands '[{"minDifficulty":null,"maxDifficulty":25,"fallbackChain":["antigravity","codex","claude-code"]},{"minDifficulty":26,"maxDifficulty":75,"fallbackChain":["codex/gpt-5.6-terra"]}]'

(This went through one design iteration during review: the first version of this PR used a single threshold + comparator (<=, <, >=, >, ==) per band, which could express a one-sided cutoff but needed two bands hand-paired to express a real range. Replaced with native two-sided bounds, which subsumes every comparator case directly — <= N is {null, N}, >= N is {N, null}, == N is {N, N} — while making an actual range a single band instead of an implicit pairing. Existing stored settings (including comparator-shaped bands saved during that iteration, and the original pre-comparator shape before that) migrate automatically — see Verification.)

3. Decision agent: one merged control (new)

The model that rates each task's difficulty before routing is itself configurable, via a single searchable provider/model picker instead of a free-text box:

• Automatic (default): tries an ordered automaticFallbackChain, same shape and same picker pattern as the difficulty bands above. In this mode the picker doubles as the fallback-order editor — checking a model toggles its membership in the chain, shown right below as a reorderable list.
• Picking a specific model instead pins the classifier to it directly, skipping the fallback order entirely.

If nothing in the fallback order is available, the classifier falls back to any launchable model, then whatever's first — a last-resort safety net, not a preference, so it isn't user-facing.

Screenshots

Decision agent picker + fallback-order editor, rendered live:

Per-difficulty model selection, rendered live — note this screenshot is from the single-comparator iteration (<= dropdown + one threshold) described above, captured before the native-range rewrite in this update. The range UI replaces that dropdown with two bounded number inputs ("min" / "max", either blank for unbounded) in the same card layout; a refreshed screenshot will follow once available, but the underlying behavior shown here — ordered fallback chain, reorder/remove, add-band, add-model-to-chain — is otherwise unchanged by the rewrite:

Verification

• npx tsc --noEmit — clean
• npx vitest run — 53/53 passing (28 original + 25 new across this PR: routable-provider regression coverage, band-range/exact-model-pin/two-sided-range cases, and settings-migration coverage for every prior stored shape)
• bb plugin build — produces real dist/ output
• Live-tested against a running bb instance at every step, not just the unit suite:
  • Confirmed a real bb autorouter route call lands on the configured decision-agent model by tracing the hidden classifier thread's actual providerId, not just trusting the setting saved.
  • Confirmed reordering the fallback chain changes which model the classifier actually runs on.
  • Confirmed a genuine three-band range configuration (0–25 / 26–75 / 76+) correctly routes a difficulty-55 task to the middle band's pinned model (benchmarkScore: null, bypassing ranking) — not just the edges.
  • Confirmed the settings-migration path against real stored data at each shape transition: the original pre-comparator shape, the intermediate single-comparator shape, and now the native-range shape all load correctly from what was actually persisted in a live KV store, without wholesale-resetting the whole settings object to defaults — a real regression caught live during development (fields added after a setting was first saved used to silently discard the whole object) and now covered by settings.test.ts for every shape.

Scope

README.md, app.tsx, benchmarks.ts, router.ts, router.test.ts, server.ts, settings.ts, settings.test.ts, components/ui/command.tsx (vendored/adapted from bb-plugin-prompt-enhancer's picker component), docs/screenshots/.