feat(providers): add Requesty provider preset

[Thibaultjaigu]

Overview

Adds Requesty to the "Start from a preset" picker in the Add Provider modal. Picking it fills in the Requesty endpoints for chat, messages and responses, so setup is just pasting an API key.

✨ New Features

• Requesty preset: New entry in packages/backend/data/provider-presets.json, placed right after OpenRouter and following the same shape. The chat, messages and responses bases all point to https://router.requesty.ai/v1. Requesty has no pi-ai builtin, so piAiProvider is openrouter, the same as Kilocode and Neuralwatt, and there's a matching assertion in the existing gateway mapping test. The notes field links the key page (https://app.requesty.ai/api-keys) and mentions the EU base (https://router.eu.requesty.ai/v1).

I left out the legacy completions endpoint because Requesty returns 404 for /v1/completions, and the openrouter-decisions alpha is OpenRouter specific. I did not add a quota checker because Requesty has no documented balance or credits endpoint.

How to test: open Add Provider, pick the Requesty preset, paste a key from https://app.requesty.ai/api-keys, then route a model such as openai/gpt-4o-mini (chat or responses) or anthropic/claude-haiku-4-5 (messages).

Checks run:

• bunx --bun vitest run --config vitest.config.ts in packages/backend: 319 files, 3539 tests passed
• bun run typecheck: pass
• bun run lint:check and bun run format:check: clean
• Live test: I built the provider draft with applyProviderPreset from the built-in catalog, then posted to each wired base. All returned 200: chat/completions and responses with openai/gpt-4o-mini, messages with anthropic/claude-haiku-4-5.

Disclosure: I work at Requesty. Happy to adjust anything to match project conventions.

[github-actions]

✅ OpenCodeReview: Review complete: 0 finding(s) across 1 selected item(s).

[github-actions]

🔍 OpenCodeReview — detailed findings

✅ Passing — no critical/high findings.

Reviewed 1 file(s), 0 finding(s) total.

[mcowger]

Thanks Thibault! Good to hear from you again (we crossed paths on Kilocode stuff before).

I'm impressed you saw this before it even ended up in a release.

This is a good add. I'm going to hold on it though because I want to add a couple more thing to the definitions, which would likely help:

1. A way to explicitly define the behavior that pi-ai covers, but for providers not represented in that library - so you don't have to pretend to be OpenRouter.
2. Defined endpoints for model and capability interrogation so that more stuff comes for free.

I'll ping you back - but thank you for the rapid PR