feat: 支持 Art 使用自定义模型供应商的图片和视频模型

### 使用场景 / Use case

希望在 Art 中使用已添加的自定义模型供应商所提供的图片生成、图片编辑、视频生成和图生视频能力，并使用该供应商配置的 Base URL、凭证和模型映射。

目前已添加自定义名称为 ChatGPT 和 Grok 的供应商。这里的名称是用户自定义显示名称，不是内置 OpenAI / xAI 来源，也不是对官方订阅接入方式的描述。

### 当前问题 / Current limitation

环境：macOS、Cindy 0.1.73、Art 1.13.4。以下观察和安装包检查针对该版本，不代表最新版本状态。

直接观察到的现象：
1. 在「模型供应商」中，自定义 Grok 已启用，Grok Imagine Image 2.0、Grok Imagine Image Quality 和 Grok Imagine Video 1.5 均已显示并打开模型开关。
2. 打开 Art 详情页「Cindy 能力」的出图选择列表，只能看到内置 xAI 来源的三个图片模型，没有自定义 Grok 来源。
3. Core 的媒体模型目录查询也只返回了三个 provider_id 为 xai 的图片模型。

截图直接确认的是自定义 Grok 图片模型未进入 Art 出图列表；没有对自定义 ChatGPT 逐模型验证，也没有发起图片或视频生成请求。因此，视频相关限制来自实现检查，不是一次已执行的视频调用失败。

#### 实现调查（供定位）

检查了已安装 Art 的 main.js、Cindy 0.1.73 的 app.asar，以及本地客户端源码：
- Art 读取 Host 的模型配置并返回 modelId / providerId，不自行连接自定义供应商端点。
- 已安装版 getImageChannelRegistry() 只注册 xd、xai、gemini、openai，没有按任意自定义供应商配置动态创建图片通道。
- listLocalProviderMediaModels() 会通过 isProviderReady(provider.id) 过滤来源；未注册通道不会被视为就绪。
- 视频侧 isVideoCatalogProviderReady() 只接受指定来源（xd / xai），模型还需通过执行别名检查。

相关源码入口：
- apps/desktop/src/main/cindy-brain/index.ts：getImageChannelRegistry、listLocalProviderMediaModels、listLocalProviderVideoModels、isVideoCatalogProviderReady
- apps/desktop/src/main/cindy-brain/imageChannelRegistry.ts：isProviderReady

这使得供应商设置中的模型可见性与 Art 的媒体可执行能力存在落差。仅让 Art 透传 providerId 或在下拉框中增加模型，并不能完成实际调用接入。

相关讨论：#3881 / PR #3875 涉及特定 xAI API-key 生图来源；本请求关注通用自定义供应商的媒体协议接入，而非仅增加一个内置来源。

### 期望方案 / Proposed solution

- 对已适配的媒体协议，允许使用自定义供应商的 Base URL、凭证和模型映射进行媒体生成。
- Art 按实际能力展示图片生成、图片编辑、视频生成和图生视频模型，并明确区分同名模型的不同来源。
- 请求始终使用用户选择的供应商，不静默改用内置来源或其他凭证。
- 视频支持覆盖任务提交、状态查询和结果获取。
- 对尚未支持的协议或缺失配置，说明不可用原因，避免供应商页已显示并启用、Art 却无解释地不显示。

可以先支持一组明确的媒体协议，再逐步扩展；不要求自动兼容任意私有协议。建议以自定义来源可选择、可正确路由并成功交付媒体结果作为验收，而非仅验证模型出现在列表中。

### 已考虑的替代方案 / Alternatives considered

已考虑使用内置供应商入口，但它不能替代指定自定义供应商及其凭证、端点的需求。

通过其他工具直接调用媒体接口可以作为另行探索的路径，但本次未验证，也不能替代 Art 中统一选择模型和接收媒体结果的体验。

Start with apps/desktop/src/main/cindy-brain/index.ts, especially getImageChannelRegistry, listLocalProviderMediaModels, listLocalProviderVideoModels, and isVideoCatalogProviderReady, then inspect imageChannelRegistry.ts for isProviderReady. Trace how custom provider configuration, model mappings, and media requests are routed. Done means supported custom media models are accurately listed, use the selected provider credentials and Base URL, and complete the applicable image or video workflow with clear handling for unsupported configurations.

Written by the indexing model from the issue text.