Add desktop custom provider setup

[wbe7]

Summary

Fixes #38975.

Adds first-class Desktop support for reusable OpenAI-compatible custom providers. The flow is intentionally generic: it is not tied to AI Router, LiteLLM, LM Studio, or any single service.

What changed

• Add POST /api/providers/custom for creating/updating custom providers in Desktop.
• Store custom provider metadata under providers: in config and keep secrets in .env via a generated key_env.
• Derive provider identity from the configured Base URL when the UI does not supply a name:
  • display name: hostname, e.g. https://ai-router.app/api/v1 -> ai-router.app
  • provider slug: ai-router-app
  • env var: CUSTOM_PROVIDER_AI_ROUTER_APP_API_KEY
• Fetch model IDs from the OpenAI-compatible models endpoint: GET {base_url}/models.
  • Example: https://ai-router.app/api/v1 -> https://ai-router.app/api/v1/models
• Persist discovered models on the custom provider so the model picker/settings can show the provider normally.
• When onboarding makes the provider active, use the first discovered model as the initial default. If model discovery fails in that path, return a clear setup error instead of requiring the user to type an internal model field.
• Update Desktop Settings -> Providers -> API keys:
  • Custom provider appears like the other provider rows.
  • API key is on the same row as the provider name.
  • Base URL is the expanded advanced field.
  • Users do not manually enter provider name, model, or key_env.
• Update Desktop onboarding Local / custom endpoint custom-provider flow to require only Base URL plus optional API key.

Notes

This keeps custom-provider credentials isolated from generic OPENAI_API_KEY, so arbitrary custom hosts only receive the key explicitly configured for that custom provider.

For local Desktop testing, the packaged renderer and Python backend must come from the same checkout. If a locally packaged app starts the already-installed ~/.hermes/hermes-agent backend from an older commit, POST /api/providers/custom can return 405 Method Not Allowed because the backend route is not present there. Use HERMES_DESKTOP_HERMES_ROOT=/path/to/checkout when testing this PR locally.

Validation

• npm run --prefix apps/desktop type-check
• npm run --prefix apps/desktop test:ui -- src/app/settings/providers-settings.test.tsx src/store/onboarding.test.ts src/components/desktop-onboarding-overlay.test.tsx
• uv run --extra dev pytest tests/hermes_cli/test_web_server.py::TestWebServerEndpoints::test_set_model_main_custom_persists_base_url tests/hermes_cli/test_web_server.py::TestWebServerEndpoints::test_set_model_main_non_custom_clears_stale_base_url tests/hermes_cli/test_web_server.py::TestWebServerEndpoints::test_create_custom_provider_persists_named_provider_key_and_active_model tests/hermes_cli/test_web_server.py::TestWebServerEndpoints::test_create_custom_provider_can_discover_models_without_user_model -q
• uv run --extra dev ruff check hermes_cli/web_server.py tests/hermes_cli/test_web_server.py
• Targeted ESLint on changed Desktop files: 0 errors, existing padding warnings remain in store/onboarding*.

[teknium1]

Thanks for the custom-provider Desktop work. This is now redundant with a later implementation already on main.

• Automated hermes-sweeper review verified that fix(desktop): collect + persist API key for custom OpenAI-compatible endpoints #43896 (4ddb03390a95d1b92349bbb9170d3f0659e56cb8) shipped Desktop URL + optional API-key setup for OpenAI-compatible endpoints, authenticated /models discovery, persistence, and reusable custom-provider registration.
• apps/desktop/src/store/onboarding.ts:801 performs the current endpoint probe, chooses a discovered model, persists it, and verifies runtime readiness.
• apps/desktop/src/app/settings/model-settings.tsx:502 routes custom/local providers into the dedicated URL + API-key setup flow.
• hermes_cli/web_server.py:5572 and hermes_cli/web_server.py:5684 persist the assignment and register the named custom-provider entry used by the picker.

The related #38975 discussion's manual-model fallback for unavailable /models endpoints is not covered by this close; this PR's own active onboarding path also requires model discovery.