feat(ai-providers): add Requesty as an AI provider

[Thibaultjaigu]

Why

As a new AIProviderType case, Requesty's raw value would sit in the synced AI settings, where no released build can decode it, and an older Mac's next push would delete the provider. The shared OpenAI-compatible transport also had controls that did nothing.

Change

• Requesty in Add Provider…: Base URL filled in, key required, a wrong key (Requesty answers 403) reported as an authentication failure. Stored as a custom provider with a preset id, so every build reads it.
• A chosen reasoning effort is sent as reasoning_effort on OpenRouter, OpenCode Zen, llama.cpp, MLX and custom providers. Gemini and Ollama lose a picker that changed nothing.
• Image attach and the effort picker follow the model a router lists, per provider.
• A new provider no longer starts on the first of hundreds of models sorted by name. A cleared Base URL saves as the default. Ollama gets options.num_predict and base64 images.

Verified

AIProviderPresetTests, OpenAICompatibleProviderRequestTests and the 403 cases fail on main and pass here. Bad-key answers and model-list shapes come from the live Requesty and OpenRouter APIs. AIProviderPresetUITests runs on CI only.

Not in this PR

• A released build syncing the settings drops the preset id; Requesty then reads as plain custom.
• A custom provider with a saved effort now sends reasoning_effort, which a strict server rejects.
• Per-model tool calling is not read; model menus stay flat.
• OpenRouter's streamed reasoning_details is not rendered.
• The Ollama changes follow its API docs, not a live server.

[datlechin]

Hi @Thibaultjaigu, thanks for the contribution. Why we don't just use the OpenAI Compatible provider instead of creating new providers?

[Thibaultjaigu]

Fair question. Custom works for Requesty today, so this is only about setup, and the delta is small. It is the same footprint as the OpenRouter entry and reuses OpenAICompatibleProvider, no new transport code:

1. It shows up by name with its own icon in Add Provider…, with https://router.requesty.ai prefilled, so nobody has to look up the base URL.
2. The key is required, like OpenRouter. Custom treats it as optional, and our /v1/models answers without a key, so on Custom a keyless setup saves and fills the model picker, then the first chat gets a 401. With the preset, Save stays disabled until a key is there.
3. The host is listed in privacy.mdx next to the other presets.

It does not add pricing, curated models or extra headers. I checked the requests the app builds against the live API: GET /v1/models returns the OpenAI list shape (about 780 models), streaming /v1/chat/completions works, a bad key gets a 403, and the EU endpoint https://router.eu.requesty.ai works the same if you edit the endpoint field.

I also rebased onto main (v0.76.0) and moved the changelog line under Unreleased.

If you would rather keep the provider list short, that is fine too: I can close this and send a docs PR instead, with a row in ai-assistant.mdx showing Requesty through Add Custom Provider… with https://router.requesty.ai/v1.