openhands-llm-auth

Add an `llm_auth_method` field plus OAuth token fields to the Settings model, create dedicated device-code/poll/refresh routes, and inject refreshed tokens into LiteLLM via `setup_llm_config`. The frontend shows an OAuth panel that hides the API-key field while connected.

Use the RFC 8628 device code flow against `https://auth.x.ai/oauth2/device/code` with the public Grok CLI client id, poll the token endpoint handling `authorization_pending` and `slow_down`, then use the access token as the LiteLLM API key with the `xai/` model prefix.

A 403 after successful login usually indicates a tier or entitlement restriction, not a bad token. Map it to a distinct error like `xai_oauth_tier_denied` without forcing re-login, and offer an API-key fallback through console.x.ai.

Yes, the dual-auth pattern stores both, with `llm_auth_method` selecting the active method. GET responses must expose only booleans like `xai_oauth_set` and never return raw tokens, and POST merges preserve OAuth fields when omitted.

Conversation setup often runs inside an existing asyncio loop, so plain `asyncio.run` crashes. Run the refresh coroutine in a one-shot thread pool with its own loop to make it nested-loop safe.