增强模型发现后的同步策略与批量操作

背景

当前管理端支持从供应商发现远程模型，但发现结果和本地 AiModel 之间的同步关系还比较轻。对于 Ollama、OpenAI-like、SiliconFlow 等模型数量较多或变化较频繁的供应商，管理员需要更清楚地知道哪些模型是新增、已存在、已变化或远端已消失。

如果同步策略不明确，后续很容易出现两个问题：远端模型变化后本地列表过期，或者同步操作覆盖管理员手动维护的显示名、分组、启用状态等配置。

目标

增强模型发现后的同步策略，让远程模型发现不只是“创建模型”，而是一个可控、可追踪、不会误覆盖本地配置的同步流程。

建议能力

• 发现结果区分新增模型、已存在模型、本地已禁用模型、远端已消失模型
• 支持批量创建、批量启用、批量禁用或忽略模型
• 对已存在模型展示差异，例如显示名、能力、endpointType、流式支持等
• 支持保留管理员手动修改的字段，避免同步覆盖本地配置
• 对远端已消失但本地仍存在的模型给出提示，而不是直接删除

建议交互

• 在发现模型弹窗中按同步状态分组
• 每个模型展示本地状态和建议动作
• 批量操作前给出影响范围确认
• 同步完成后刷新供应商下的模型列表
• 对会覆盖本地字段的操作提供明确提示

后端/API 建议

• 发现接口可以返回结构化同步建议，而不是只返回远程模型列表
• 需要明确哪些字段由远程发现维护，哪些字段由管理员本地维护
• 可以考虑为 AiModel 添加来源/同步相关标记，便于后续诊断和清理
• 与 issue #11 中 endpointType 推断后移的方向保持一致

非目标

• 不要求自动定时同步远程模型
• 不要求远端消失时自动删除本地模型
• 不要求支持跨供应商迁移模型配置

验收标准

• 管理员可以清楚区分发现结果中的新增、已存在和远端消失模型
• 管理员可以批量创建或更新发现到的模型
• 同步不会静默覆盖管理员维护的本地字段
• 远端消失的模型不会被静默删除，管理端会明确提示

No files or tests are named. Start by tracing the model discovery flow, AiModel management, and the related endpointType direction from issue #11; define remote-versus-local field ownership and sync states before implementing the suggested UI and API changes. Done means the acceptance criteria are met without silently overwriting local fields or deleting disappeared models.