feat(providers): 新增 Requesty 润色渠道

[Thibaultjaigu]

摘要

没有关联 issue。

新增 Requesty（OpenAI 兼容的 LLM 网关）作为内置润色渠道，注册位置与现有 OpenRouter 润色渠道一一对应。Requesty 是可选渠道，不会成为默认渠道，也不进入任何自动选择逻辑。

修复 / 新增 / 改进

• Core provider_rules.rs：LLM_PROVIDER_TYPES 增加 requesty，默认地址 https://router.requesty.ai/v1，默认模型 openai/gpt-4o-mini（已在线上 /v1/models 目录核对）
• Core cloud_providers.rs：SHARED_CLOUD_LLM_PROVIDER_TYPES 增加 requesty
• Core polish.rs：is_builtin_llm_provider 增加 requesty，温度沿用内置渠道默认值
• 前端 ProvidersSection.tsx 的 LLM_LABELS 与 Overview.tsx 的名称映射
• 八种语言的 settings.providers.presets.requesty 文案，以及 linux-egui/assets/ui-locales.json
• mock-provider-descriptors.json 与 provider-descriptors.generated.json 按 OpenRouter 条目做了对应的增量修改
• README 中英文润色渠道列表
• 新增单元测试 requesty_descriptor_supplies_defaults_formats_and_credentials

兼容

• 不包含：Requesty 语音转写（目录里没有音频模型）；思考开关参数（OpenRouter 的 reasoning 对象是它自己的格式，这里保持不下发，与 CometAPI 相同）
• 对现有用户 / 本地环境 / 构建流程的影响：无，只是在渠道列表里多一个可选项

测试计划

• 命令：cargo test --locked -p openless-core、npm test（含 tsc && vite build）、rustfmt --check
• 结果：Core 865 通过、1 忽略；前端测试全部通过。rustfmt --check 与 prettier --check 的既有提示在 upstream/beta 上同样存在，本次改动没有新增
• 证据路径：在本地用 Core 自己的 provider_descriptor("requesty") 和 OpenAICompatibleLLMProvider::polish 跑真实请求，模型 openai/gpt-4o-mini，Chat Completions、Responses、Messages 三种请求格式都返回了正常的润色结果（HTTP 200）

手动测试：设置 → AI 服务 → 添加渠道 → Requesty，填入在 https://app.requesty.ai/api-keys 获取的 key，模型保留 openai/gpt-4o-mini 或改成任意 vendor/model 形式的 id。文档：https://docs.requesty.ai

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

[appergb]

Requesty 润色渠道已随 2.0.0-Beta.3 集成进入 beta 分支（提交 51f6f4c），代码已实际合入，此处补关并随 v2.0.0-Beta.3-tauri 发布。感谢贡献！