feat: add Requesty as an OpenAI-compatible AI driver

[Thibaultjaigu]

Add Requesty as an OpenAI-compatible AI driver

This adds Requesty (https://router.requesty.ai/v1) as a dedicated AI driver, mirroring the existing OpenRouter driver in server/ai/drivers/.

Implementation

Requesty is an OpenAI-compatible gateway that speaks the same Responses wire protocol (POST /v1/responses) the OpenAI and OpenRouter drivers use, so the new driver reuses the shared responses-shared.ts adapter.

• New server/ai/drivers/requesty.ts — mirror of openrouter.ts: base URL https://router.requesty.ai/v1, Bearer auth, and a /v1/models parser that maps Requesty's real field shape (context_window, input_price/output_price, supports_tool_calling/supports_vision/supports_caching, api == "chat") rather than blindly copying OpenRouter's field names.
• New server/ai/drivers/requesty.test.ts — 8 tests (auth mode, capability/price/context mapping, chat-only filter, tool-calling default, non-OK error, no-key error).
• Registered in server/ai/drivers/index.ts, server/ai/runtime/types.ts (AiProviderId), server/ai/handlers/credentials.ts, server/ai/handlers/models.ts (VALID_PROVIDERS), src/admin/ai/api.ts, and src/admin/pages/ai/tabs/ProvidersTab.tsx.
• Added Requesty to the provider lists in README.md and docs/features/agent.md.
• No DB migration needed — migration 012 already dropped the provider enum CHECK; provider_id is validated at the app boundary.

Verification

• tsc -b: clean.
• bun test (driver + architecture + AI suites): 163 pass / 0 fail, including the new requesty.test.ts and the ai-driver-isolation gate (the driver uses direct HTTP, no SDK).
• ESLint on touched files: clean.
• Live test against the real endpoint: chat completion openai/gpt-4o-mini → 200; POST /v1/responses → 200 with the same SSE events the shared translator handles; GET /v1/models → 200 with 596 models.

I work at Requesty. This mirrors the existing OpenRouter provider as closely as possible. Happy to adjust or close it if it's not a fit.