Add OAuth 2.0 Support

[iBreaker]

Problem

NYRO currently authenticates upstream providers primarily through static API keys. This limits compatibility with providers that require OAuth 2.0 access tokens and token refresh handling.

To support OAuth-based providers without introducing unnecessary schema or control-plane complexity in the first phase, the backend needs a minimal and explicit authentication model at the provider level.

Proposal

Introduce minimal OAuth 2.0 provider support in the backend by extending the providers model with the following fields:

• auth_mode
• access_token
• refresh_token
• expires_at

auth_mode is restricted to the following values:

• api_key
• oauth

Backend credential selection should follow auth_mode:

• api_key -> use provider.api_key
• oauth -> use provider.access_token

This phase focuses on backend schema and runtime authentication behavior only.

Scope

• Add backend persistence fields to providers:
  • auth_mode
  • access_token
  • refresh_token
  • expires_at
• Restrict auth_mode to api_key and oauth
• Update backend provider loading and persistence logic to read/write these fields
• Update runtime credential resolution to select:
  • provider.api_key when auth_mode = api_key
  • provider.access_token when auth_mode = oauth
• Keep existing API key behavior unchanged by default
• Ensure schema migration works for supported storage backends

Non-goals

• No WebUI changes
• No full OAuth authorization flow implementation in this issue
• No dedicated OAuth session or binding tables in this phase
• No user/account identity modeling
• No scope management or advanced token metadata handling
• No token refresh orchestration beyond storing refresh_token and expires_at

Acceptance Criteria

• providers schema includes:
  • auth_mode
  • access_token
  • refresh_token
  • expires_at
• auth_mode only accepts:
  • api_key
  • oauth
• Existing providers continue to work with auth_mode = api_key
• Backend runtime selects credentials based on auth_mode
• When auth_mode = api_key, requests use provider.api_key
• When auth_mode = oauth, requests use provider.access_token
• Migrations are applied successfully for supported backends
• Backend tests pass with the new schema and auth selection behavior