[Feature] [OpenRouter] Implement Full Open Router API Support (UI + Backend)

[HexdoAI]

Parent Epic: #56
Depends on: #61 (This issue introduces the "Provider Type" UI)

🎯 Goal

Implement end-to-end support for the Open Router API, allowing users to add it as a custom model provider.

💻 UI Requirements (Frontend)

1. Add "Open Router" as an option to the "Provider Type" dropdown menu (introduced in [Feature] [Azure] Implement Full Azure OpenAI Support (UI + Backend) #61).
2. When a user selects "Open Router", the form must show the following fields:
   • API Key (Required)
   • API Address (Optional: Allow users to specify a custom/proxy endpoint instead of the default https://openrouter.ai/api/v1)
   • HTTP-Referer (Optional: Allow users to specify a custom HTTP-Referer header, as required by some Open Router configurations)

⚙️ Backend Requirements

1. Modify the "save model" API to store the provider_type: 'OpenRouter' and its associated fields.
2. The backend logic must check the provider_type for the model.
3. If the provider_type is "Open Router", the system must route the API call to an llm.openrouter.js client (this client may need to be created or updated).
4. The llm.openrouter.js client must correctly:
   • Use the API Key in the Authorization: Bearer [API Key] header.
   • Target the API Address (or the default Open Router endpoint if not provided).
   • Include the HTTP-Referer header in the request if one was provided by the user.

✅ Acceptance Criteria

• A user can successfully add and save an Open Router API configuration via the UI.
• The system can use this configuration to successfully make calls to the Open Router API.