docs(changelog): #7325 补 808611/808612/808613 与 hotel_ready 组合态提示口径

#7325 的 AC-21 字面要求 changelog 覆盖这三个码的文案与
「hotel_ready=false ∧ 有 CONFIRMED 行」的提示口径，首发时漏了：
808611/808613 全文零命中、808612 只出现在测试记录表格里。

三个码属 #7324 的段位但三个新端点都会返回（归属门在编排层前置），
前端只按本单新增的 8 个码做分支会漏掉最常见的三种拒绝。

顺带填 target_release=hl-ui@d487d2be：50c0e53 把 frontend_status 置为
verified 但 target_release 仍为空，校验器规则「verified 必须填写
target_release」会让该文件此后任何编辑都推不上去。取值来自同一份
frontmatter 的 frontend_ref，不是猜的版本号；mmg 若有正式版本号请覆盖。

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

changelogs-v2/2026-09/11_7325_团期房务按日订房确认H7-H8-预检-新增接口-管理后台.md

@@ -10,7 +10,7 @@ gateway_status: "verified"
 frontend_status: "verified"
 frontend_owner: "mmg"
 frontend_ref: "d487d2be"
-target_release: ""
+target_release: "hl-ui@d487d2be"
 verified_at: "2026-09-11"
 status_note: "2026-09-11 已部署测试服并经网关实测（squash dfd5a8f6f，PR #7497）。部署面只有 hl-order-service-v3 一个服务（两条独立路径核过：53 个改动文件全在该模块；对 hl-common / hl-gateway / 其它服务的命中数 = 0），未改 hl-common-*，无消费方需连带滚。Flyway V20260910_302 在测试库执行成功（flyway_schema_history 版本 20260910.302 success=1）。⚠️ 本篇起草时写错过一条并已更正：原写「GET /confirm-check 任何后台角色都能调」——不成立。读端点虽然不标 @HouseWriteGuarded、不走拦截器，但在编排层入口直接调 HouseReadGuard.assertHouseReadPermission()（GroupBatchRoomDayConfirmManager.java:489），非房务角色同样 808090。错因是只枚举了「注解+拦截器」一条机制就下了否定结论；2026-09-11 测试服实测（test_admin/CUSTOMIZER 打 GET 得 808090）与源码调用点双向坐实后已在「关键变化 1」更正。网关零改动：hl-gateway 自 2026-09-07 21:53 起未重启（jar mtime 与进程 lstart 两条路径核过），三个新端点均返回业务层响应而非路由未命中，证明既有 /v3/admin/** 通配已覆盖。⚠️ 尚未验证：H7/H8 真实确认业务逻辑未跑通——取证用的团期处于未认领态，POST 先撞 808612，需先造「整团抢单→提交需求→确认基线」数据链才能触达，本轮未做，如实标为未验证而不写「正常」。 前端已交付(commit d487d2be):confirm-check 预检+按日 confirm+整团 confirm 三端点接入看板详情,先预检展示 ready/dayReady false 只列差额/阻塞名单不调写口,写口组长 808091 隐藏,808616 常量随连锁重算上线删除,808602 右开区间口径前端本已对齐(注释补记);错误码一律拦截器透 message 不建字典。"
 updated_at: "2026-09-11"
@@ -67,6 +67,42 @@ base: "dev-v3"
 
 ---
 
+### 4. 三个端点还会返回 #7324 的归属门 / 日期门错误码（808611 / 808612 / 808613）
+
+这三个码**不是本单新增**（属 #7324 的 808611-808619 段），但**三个新端点都会返回它们**——
+归属判定由 `HouseGroupBatchClaimGuard` 在编排层前置执行，早于本单任何业务判定。
+前端如果只按本单新增的 8 个码做分支，会漏掉最常见的三种拒绝。
+
+| 码 | 文案（可直接展示） | 什么时候出现 |
+|---|---|---|
+| **808611** | 团期出发日或结束日缺失，无法录入订房计划 | 团期没配出发日/结束日，换算不出入住日历 |
+| **808612** | 该团期尚未被房务认领，请先到团期抢单池认领 | 团还在抢单池里没人认领 |
+| **808613** | 该团期由其他房务认领，无权操作 | 团被别的房务认领了 |
+
+🔴 **808612 是联调阶段最高频的一个**：本单 2026-09-11 的网关实测里，
+`ROOM_MANAGER` 打 `GET /confirm-check` 拿到的就是 808612——因为取证用的团没被认领。
+**前端从看板进入确认页时，团必然已被本人认领，正常不会撞到**；但从别处深链进来、
+或团在此期间被释放/接管，就会返回它。**文案已可直接展示，且它指明了出路（去抢单池认领）。**
+
+### 5. `hotel_ready=false` 且存在 CONFIRMED 计划行时，看板要给醒目提示
+
+这是一个**组合态**，不是单一字段能表达的：团里已经有确认过的订房计划行，但整团的
+`hotel_ready` 仍是 `false`。
+
+出现原因：本单的重算/重置路径（`resetHotelReady` → 软删失活分房行 → 重跑 Allocator →
+按户重判「分平」）会在管理员改需求后，把已经平了的户**退回未完成**，于是
+`hotel_ready` 被清掉，而此前确认过的 CONFIRMED 计划行**仍然留在库里**。
+
+**这两个信号单看都不足以说明问题：**
+
+- 只看 `hotel_ready=false` → 像是「还没开始订房」，但实际上已经订了一部分；
+- 只看「有 CONFIRMED 行」→ 像是「订好了」，但实际上团期并未就绪。
+
+**所以提示必须由两者的合取派生**，由 #7324 的 H1 看板列表 / H2 详情负责渲染
+（本单只交代口径，不改 #7324 的端点）。建议文案方向：「本团已有已确认的订房计划，
+但需求发生过变更，需重新确认后团期才会就绪」——**不要渲染成「未订房」**，
+那会让房务重头再订一遍。
+
 ## 一、背景
 
 `#7325` 交付两块能力补齐团期房务确认链路：