feat(local): SuperGrok OAuth for xAI Grok models

[just-cameron]

Summary

• Add local xAI Grok OAuth (SuperGrok / X Premium+) via device-code login at auth.x.ai (no XAI_API_KEY required)
• Wire dual-auth for xAI: SuperGrok OAuth + existing API-key path
• Live-list models from api.x.ai/v1/models when OAuth/API credentials exist (surfaces grok-4.5, multi-agent, etc.)
• Label SuperGrok models clearly in /model as (SuperGrok) vs (API key)
• CLI: letta --backend local connect xai-oauth (aliases: grok-oauth, grok)

Scope

Local backend only. Constellation / Cloud xai_oauth BYOK is intentionally out of scope for this PR.

Usage

letta --backend local connect xai-oauth
letta --backend local
# /model → Grok 4.5 (SuperGrok), etc.

Test plan

• bun run check
• Unit tests for device-code OAuth, connect aliases, model catalog, SuperGrok labeling
• Manual: bun run dev -- --backend local connect xai-oauth → browser device code → success
• Manual: /model shows Grok models with (SuperGrok) labels when only OAuth is connected
• Manual: xai API-key connect still works and labels as (API key)
• Manual: API-mode connect xai-oauth points users at local backend

[just-cameron]

I manually evaluated everything here and it works well.

[overlord-letta]

Overlord (agent-c2adbf5c-8419-4211-8cd8-3740db164974)

Thanks for putting this together. I found several issues that should be fixed before merge:

1. Live xAI model discovery advertises models the runtime rejects. localModelDiscovery: "openai-compatible" adds discovered xAI handles to /model, but xAI has no dynamic createCustomModel path. A discovered handle is selectable and then fails in resolvePiModelForAgent with Unknown model. Please either wire discovered xAI models into runtime resolution or remove discovery from this change.

2. TUI OAuth connect leaves the model cache stale. The available-model cache is warmed at startup. The xAI /connect success path neither clears it nor forces a refresh/open of /model, so newly available models can remain absent for up to five minutes. Please invalidate and refresh consistently with the other provider-connect paths.

3. One xAI login opens the browser twice. xai-oauth.ts invokes both onDeviceCode and onAuth, while the generic local OAuth adapter opens the URL in both callbacks. Please make browser opening single-owner and add an integration test around runLocalOAuthConnectFlow, not only callback-level tests.

4. xAI API-key and OAuth credentials overwrite each other. Both modes persist under provider key xai, so saving OAuth replaces an existing API-key record and vice versa. If these modes are intentionally exclusive, the UI needs an explicit replacement warning. Otherwise, storage/auth selection needs to represent both.

5. The existing provider-selector test is red. The subscription search now includes xai-oauth, but provider-selector.test.ts still expects only the previous three providers.

I reproduced the discovered-model runtime failure and credential overwrite with focused probes, and reproduced the provider-selector test failure. I did not obtain a complete-suite green result, so this is not ready to merge yet.

[just-cameron]

Addressed the above.