docs: 答复前端 #7324 后端需求（后端零改动）+ 补 #7322 我的团不过滤 batch_status

前端据 H1 看板过滤 CANCELLED 的行为，推断「整团释放」按钮无可达路径。
该推断的关键环节不成立：我的团（GET /v3/admin/order/grab-pool/my-claims/
group-batches）刻意不按 batch_status 过滤，H2 详情也没有阶段闸门，
CANCELLED 团期经「我的团 → H2 详情」完全可达。

根因在我方：#7322 的 changelog 从未写过这条行为，前端看不到 javadoc。
本次一并补记，并在需求单上答复 status=answered-no-backend-change。

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

changelogs-v2/2026-09/10_7322_团期整团抢单与抢单池分流-新增接口-管理后台.md

@@ -10,10 +10,10 @@ gateway_status: "not_required"
 frontend_status: "verified"
 frontend_owner: "mmg"
 frontend_ref: "745cd9b8"
-target_release: ""
+target_release: "hl-ui@745cd9b8"
 verified_at: "2026-09-10"
 status_note: "本篇覆盖 PR #7436（合并提交 ab4118a01）。2026-09-10 已部署测试服（HEAD 6d41d6148，已验 ab4118a01 为其祖先），Flyway V20260910_301 执行成功，order_group_batch 三列 house_claimer_id/house_claimer_name/house_claimed_at 已落库。32 条验收项中 28 条已取证，含用 5 个真实登录账号过网关实测的归属与接管链路。后台菜单（sys_menu）的两行抢单池入口已由 PR #7467（squash 7f791a250，hl-user-service 的 V20260910_001）补上。⚠️ 部署两条：① #7322 的部署清单原本不含 hl-user-service，本次起必须带上；② 菜单树按 roleId 缓在 Redis（cache:menu:tree:role:{roleId}，TTL 3600s），Flyway 直连 DB 不触发失效，部署后需 DEL cache:menu:tree:role:* 否则最长要等一小时。前端已交付(commit 745cd9b8):新增团期抢单池页(抢单池·团期+我的团两 Tab,含超管团级接管)与普通抢单池独立页,orders 页摘除 pool scope,BatchHero 接负责房务三字段;checkpoint 全绿。"
-updated_at: "2026-09-10"
+updated_at: "2026-09-11"
 base: "dev-v3"
 ---
 
@@ -392,7 +392,7 @@ Authorization: Bearer <持 SUPER_ADMIN 的管理端 token>
 |---|---|---|---|---|---|
 | scope | Query | String | 否 | `mine`（默认）/ `all` | 普通房务传 `all` → 808092 |
 | keyword | Query | String | 否 | ≤32 字 | `batchNo`/`productName` 模糊 |
-| batchStatus | Query | String | 否 | 团期九态任一，非法值 400 | — |
+| batchStatus | Query | String | 否 | 团期九态任一，非法值 400 | **透传，不做任何过滤**——含 `CANCELLED`。不传 = 全部已认领团（含已流团）。⚠️ 与 H1 看板语义相反，详见下方补记 |
 | needsReconfirm | Query | Boolean | 否 | `true`=只看 `requirement_confirmed=0` 的团 | 待管理员重新确认 |
 | departDateFrom / departDateTo | Query | LocalDate | 否 | — | 出发日区间 |
 | claimedAtFrom / claimedAtTo | Query | LocalDateTime | 否 | `yyyy-MM-dd'T'HH:mm:ss` | 认领时间区间 |
@@ -415,6 +415,30 @@ Authorization: Bearer <持 SUPER_ADMIN 的管理端 token>
 
 （字段取自 `HouseMyGroupPageRespVO.java`、`HouseMyGroupItemRespVO.java`、`HouseMyGroupStatsVO.java`。）
 
+#### 🔴 补记（2026-09-11）：本列表**不按 `batch_status` 过滤**，已流团（CANCELLED）团期就在里面
+
+这条行为原本就是后端的刻意设计，但**本篇首发时漏写了**，在此补上。
+
+- `HouseGroupGrabService.listMyGroups` 的 javadoc 原话：「**不限制 batch_status**：已认领的团可能已流团 / 已结束，本单不自动释放指针，**房务仍要看得见并手动释放**」；
+- 服务层 `GroupBatchService.pageHouseClaimed` 把查询条件**原样下推**，零注入；
+  对照：同一个类里的 `pageHouseGrabPool`（团期抢单池）却**强制**写死 `REQUIREMENT_CONFIRMABLE_STATUSES`。
+  一个注入、一个不注入，是刻意区分，不是遗漏。
+
+**与 H1 房务团期看板（#7324）的语义正好相反，两个列表不能套用同一套前端逻辑：**
+
+| | 本接口（我的团） | H1 看板 `GET /v3/admin/house/group-batches` |
+|---|---|---|
+| 不传 `batchStatus` | 全部已认领团，**含 CANCELLED** | 默认四态，**不含 CANCELLED** |
+| 传 `batchStatus=CANCELLED` | **只看已流团的团**（可当「待释放」筛选用） | 被**静默丢弃**并回退默认四态 |
+
+**这条为什么要紧**：「整团释放」写口 `POST .../room-plans/release-all` 仅对 `CANCELLED` 团期放行，
+而 H2 详情 `GET /v3/admin/house/group-batches/{groupBatchId}` **没有阶段闸门**（只判归属：未认领 808612 / 他人认领 808613）。
+所以拿一个 CANCELLED 团的 `groupBatchId` 去打 H2，是能打开的——**本接口就是拿到那个 id 的地方**。
+
+前端 2026-09-11 曾据 H1 的过滤行为推断「整团释放按钮无任何可达路径」并提了后端需求
+（`backend-requests/2026-09/11_7324_放开H1看板batchStatus过滤CANCELLED-整团释放可达.md`）。
+那个推断在当时掌握的信息下是合理的——**缺的正是本篇漏写的这一条**，不是前端疏忽。
+
 #### 请求示例
 
 ```json