Add Requesty as an LLM provider

[Thibaultjaigu]

Summary

Re-adds Requesty as an LLM provider, this time wired through every code path a provider needs, following the shape of the OpenRouter and MiniMax integrations.

Depends on AgentiLoop/AgentTools#2, which adds APIProvider.requesty. The Xcode project pins AgentTools to the 1.0.0 ..< 10.0.0 range, so once that lands and a tag is cut this builds without further changes here.

Context

#25 added Requesty but, as the removal noted, the implementation was never completed: no keychain entry, no model catalog fetch, no settings section, no fallback chain or tools view support. This PR does all of that. Nothing from the old attempt is reused.

Requesty is an OpenAI-compatible router (https://router.requesty.ai/v1), so requests go through the existing OpenAICompatibleService path via the registry, exactly like MiniMax. No new service type.

Changes

Swift (12 files, all pre-existing since project.pbxproj lists sources explicitly):

• Services/LLMProviderSetup.swift: requesty LLMProviderConfig (.cloudAPI, .openAI protocol, chat and models URLs, streaming/tools/vision/systemPrompt) registered after openRouter.
• Services/KeychainService.swift: case requesty = "com.agent.requesty-api-key".
• AgentViewModel/Core/AgentViewModel.swift: requestyAPIKey (keychain backed), requestyModel (UserDefaults), requestyModels, isFetchingRequestyModels.
• AgentViewModel/Features/ModelFetching.swift: fetchRequestyModels() and a catalog fetcher for GET /v1/models that keeps entries with a nonzero context_window and supports_tool_calling == true (the loop is tool driven). Ids are already provider/model, so the id is used as the display name.
• AgentViewModel/TaskExecution/Setup.swift: .requesty arm in resolveProviderAndModel (model name and vision detection); service construction falls through to the existing OpenAI-compatible default.
• AgentViewModel/Core/Colors.swift, AgentViewModel/Messages/Compression.swift, AgentViewModel/Features/ScriptTabs.swift: temperature, context window and global model / API key / display name arms, matching OpenRouter.
• Views/Settings/SettingsView.swift: Requesty section with LockedSecureField API key, model text field or picker, and refresh button.
• Views/Settings/FallbackChainView.swift, Views/Tabs/NewMainTabSheet.swift, Views/Tools/ToolsView.swift: model option and default model arms.

Docs: the five READMEs go from 18 to 19 providers and gain a Requesty row after OpenRouter.

Intentionally not touched: the OpenRouterProtocol / Anthropic protocol switch (OpenRouter only), the OpenRouter free tier 429 handling in ErrorHandler.swift, default fallback chains, judge or auto selection lists (OpenRouter is in none of them).

Verification

• Exhaustiveness: every file with a case .foundationModel arm has matching .openRouter and .requesty counts; the remaining switch provider sites have default:. Compiling AgentTools from the Add Requesty to APIProvider AgentTools#2 branch and typechecking the changed files against it produced no "switch must be exhaustive" errors, and a control switch that omitted .requesty did fail with add missing case: '.requesty'.
• Live GET https://router.requesty.ai/v1/models returns 200 (with or without a key), 725 entries, 694 with supports_tool_calling, all with a nonzero context_window.
• I could not run a full xcodebuild on this machine (no macOS 26 SDK), so please give it one build in Xcode with AgentTools bumped to a tag containing .requesty.

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

[Thibaultjaigu]

CI note: the only compile error in the macOS run is type 'APIProvider' has no member 'requesty' (ModelFetching.swift:968), which is the AgentiLoop/AgentTools#2 dependency. Everything else builds. Once that lands and a tag is cut, this should go green without changes.

[AgentiLoop]

Updated AgentTools and Agent repos. We will probably move APIProvider.swift to the main app in a future update and try to consolidate some of these entries, but not today. There is some risk involved.