feat(console): 注册 grok-imagine-video-1.5 并支持原生 1080p

[741075810]

背景

Console 通道目前只注册了 grok-imagine-video（v1），视频生成里把上游模型名硬编码成了 grok-imagine-video。实际上 x.ai 已提供 grok-imagine-video-1.5，且该模型原生支持 1080p（v1 只有 480p/720p）。本 PR 把 1.5 接进来，并让分辨率与计价随模型区分。

改动

• 注册模型：console/catalog.go 的 mediaCatalog 增加 grok-imagine-video-1.5（Video 能力）；model_repository.go 的路由发现把它与 grok-imagine-video 一并识别为 Video 能力。
• 按模型分流：provider.VideoRequest 新增 UpstreamModel 字段，gateway/video.go 透传当前路由的上游模型；console/media.go 的 GenerateVideo 不再硬编码 grok-imagine-video，改用请求携带的模型名（缺省仍回落到 grok-imagine-video，保持向后兼容）。
• 分辨率规则：基础 grok-imagine-video 维持仅 480p/720p；grok-imagine-video-1.5 起放行 1080p。
• 计价：audit/pricing.go 补齐 grok-imagine-video-1.5 的 1080p 档（x.ai 官方 $0.25/s，即 2_500_000_000 ticks/s），并对基础 grok-imagine-video 的 1080p 明确返回不支持，避免误计价。
• 测试：更新 console_test.go 的路由数量断言（11→12），并在 pricing_test.go 增加 1.5 的 1080p 估价与还原用例、基础模型拒绝 1080p 的用例。

验证

• go build ./...、go vet 通过。
• go test ./internal/infra/provider/console/ ./internal/domain/audit/ 全部通过。

说明

• 本 PR 只涉及 Console 视频模型注册 + 1080p 分辨率/计价，是最小、自包含的一块；不改前端、不改上传/参考图数量等其它行为。

[baiya123]

请问 是否存在这个问题 视频生成的 reference_images 被错误当作首帧

[741075810]

@baiya123 这个问题我们注意到了，也做了实测。

先直接回答：本 PR 不涉及这段逻辑。#896 只做模型注册（grok-imagine-video-1.5）、上游模型名透传、以及按模型放行 1080p 与补齐计价；consoleMaxVideoImages 在本 PR 里保持为 1，image / reference_images 的分流逻辑一行未动。所以 #900 描述的行为在 main+#896 上既没被引入也没被修复，语义修复在 #885。

不过 #900「预期行为」的第三条 —— 两个字段可以同时传递并保持各自语义 —— 经实测上游不支持。这也是我们没把这块一起推上来的原因：不是遗漏，而是目前还没找到能同时表达「首帧 + 参考图」的实现路径。

实测记录（2026-08-13，Console POST /v1/videos/generations）

1）同时传 image 与 reference_images → 400，两个模型报错完全相同：

{"code":"invalid-argument","error":"Cannot specify both 'image' and 'reference_images'. Use 'image' for image-to-video or 'reference_images' for reference-to-video."}

grok-imagine-video 复现，grok-imagine-video-1.5 复现（同一文案）。

上游把这两个字段设计成二选一的两种生成模式（image-to-video vs reference-to-video），不是可叠加的两个输入槽。

2）reference_images 只传 1 张 → 200 合法，走 reference-to-video。所以 #900 的第 1 条是对的：单张参考图被强制转成首帧确实是 bug。

3）reference_images 上限是 7，且是单字段上限、不是与 image 合计：8 张 → 400 Too many reference images: 8. Maximum allowed is 7.（两个模型分别实测）。

结论：在上游放开之前，网关侧能做到最好的是两个字段同时出现时本地直接 400 并说明用法，不要让用户去吃上游报错。我们还在看有没有别的路子能达到同样效果（例如先 image-to-video 出片、再走 /v1/videos/edits 叠参考风格 —— 这条尚未验证），有结果会同步过来。

复测提醒：Console 团队级限频很紧（实测约 60 RPM，grok-imagine-video-1.5 另有约 2 RPS），而且 429 的优先级高于图片数量校验（实测优先级：422 反序列化 → 404 模型不存在 → 429 配额 → 400 图片数量 → 400 图片元素 → 400 prompt 为空）。连发用例很容易把配额错误误读成接口契约，建议每个用例换一个满额账号、用例之间隔 ≥25 秒。

另外说明本 PR 与 #885 的关系：#885 分支目前已包含模型注册与 1080p 这两块，若 #885 先合入，本 PR 即为冗余，我会主动 close。两者都改到 console/media.go、catalog.go、provider.go、audit/pricing.go，建议先合体量小的一方再让另一方 rebase，冲突面最小。

[741075810]

#885 已合入 main，本 PR 的三项内容（注册 grok-imagine-video-1.5、透传上游模型名、1.5 的 1080p 分辨率与计价）都已在 main 上实现，因此这里按前面说的主动 close，避免占用 review。

实测过程中另外发现两处 main 上仍与上游行为不一致的地方（reference_images 上限应为 7 而非合计 8、reference-to-video 在基础模型上时长上限 10s），已另开 #909 跟进，只动 console/media.go 与 console_test.go。

关于 @baiya123 问的 #900：image 与 reference_images 同时传递上游会 400（Cannot specify both 'image' and 'reference_images'.），两个模型都复现，详见本 PR 上面那条评论里的实测记录。