docs: 广告位设计补部署顺序硬约束（ov 先 cn 后，DTO IsIn 整批拒收已核实）、广告图 2MB 上限、量级假设登记

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/plans/2026-09-28-广告位轮播-设计方案.md

@@ -87,7 +87,9 @@ model ads_ov {
    编辑换图：新终键生效，旧终键对象不回收（OSS 生命周期兜底，与 banner 流同款）。
 
 - StoragePort 现有 presignPut/head/copyIfAbsent 全复用，零新增存储能力。
-- 上传大小/类型约束沿用契约 UPLOAD_MAX_BYTES 与 image/jpeg|png|heic 白名单。
+- 上传类型白名单沿用 image/jpeg|png|heic；**广告图不走变体流水线、原图直出
+  且轮播多张同屏，字节上限收紧为 ≤2MB**（独立于 UPLOAD_MAX_BYTES 的 50MB——
+  banner 一页一张可宽松，广告按运营素材实际量级收紧；uploads init 即校验）。
 
 ## 4. 同步链（全部为既有模式的机械扩展）
 
@@ -125,6 +127,8 @@ imageStagingKey 必须为本服务签发的 staging 键。
   并列 createdAt 升序；imageUrl=presigned GET（TTL=SIGNED_URL_TTL_SECONDS）。
 - 无广告返回空 items（非 404）。不加独立限速档（观众页单次加载调用一次，
   与公开相册读同量级；登记说明）。
+- **量级假设**：公开端点为 ads_ov 全表捞 + 应用层过滤，假设广告 ≤ 百条
+  （运营现实 <20）。远超时再优化（索引/缓存），登记非本次范围。
 
 ## 6. 观众页（viewer）
 
@@ -176,6 +180,12 @@ imageStagingKey 必须为本服务签发的 staging 键。
 
 ## 10. 部署注意（实施时展开）
 
+- **上线顺序硬约束（2026-09-28 复核发现）：ov api 必须先于 cn api 升级**。
+  ov sync-inbox 的 DTO 对 entityType 有 `@IsIn(SYNC_ENTITY_TYPES)` 枚举校验
+  （services/api/src/sync-inbox/dto.ts）——旧 ov 代码收到 `'ad'` 事件会**整批
+  400 拒收**（批量数组整体校验，同批 photo 事件连带被拒 → 照片同步停摆至 ov
+  升级）；对账消费路径同理。安全窗口：ov 升级并验证 → cn 升级（才开始可能
+  产生 ad.* 事件）。web 双端镜像无顺序约束（无广告时 UI 不渲染）。
 - 双库迁移（cn/ov 各自 migrate-deploy）先于新镜像 up；
 - server 镜像 + 双端 web 镜像同 tag 滚动；**api 容器重建后 web 一并 restart**
   （既有坑位）；