# 房务订单详情新增显式「回配」动作标志 `canReopen`——前端停用启发式判断

> 模块：管理后台 · 房控台 · 房务订单详情
> 类型：**后端修改(已合并 dev-v3 + 部署测试服 + API 实测)** + 前端接入
> 日期：2026-07-01 · 关联 PR #4707 / 工单 #4706
> 背景：反馈「还没最终确认的订单为什么显示回配」。根因是后端原先**不产任何『已确认可回配』信号**，前端只能靠 `house_status=CLAIMING` / `status=PROCESSING` 等**共享状态列启发式**判断「回配」——而 reopen 把已确认单退回后与「首次配房中」逐列一致，故这些共享列对**未最终确认的普通配房中订单同样命中**，必然误显回配。现后端补显式标志，前端改读它。

## 【前端 · 房控台】需改动

### 房务订单详情 `actions` 新增 `canReopen`
`GET /admin/house/orders/{orderId}` → `data.actions` 现在除 `canTransfer` / `canFinalize` 外，**新增 `canReopen`**（与前两者同结构）：

```json
"actions": {
  "canTransfer": { "enabled": ..., "code": "TRANSFER", "label": "转单", ... },
  "canFinalize": { "enabled": ..., "code": "FINALIZE", "label": "最终确认", ... },
  "canReopen":   {
    "enabled": true,
    "code": "REOPEN",
    "label": "回配",
    "disabledReason": null,
    "endpoint": "POST /admin/order/hotel-requirements/{requirementId}/reopen"
  }
}
```

- **`enabled`**：`true` **当且仅当** `house_status=CONFIRMED`（已最终确认）**且**当前登录人是该单房务持有人（claimer）。与 reopen 接口服务端守卫同源。
- **`disabledReason`**：`enabled=false` 时给禁用文案——非已确认→「仅已最终确认的订单可回配」；已确认但非本人持有→「仅本人持有的订单可回配」。
- **`label`**：固定「回配」。

### 前端改法（关键）
1. 「回配」按钮的**显隐 / 可点**改为**只读 `actions.canReopen.enabled`**，按钮文案用 `actions.canReopen.label`，禁用态可展示 `disabledReason`。
2. **停用**原先基于 `house_status==CLAIMING` / `status==PROCESSING` / `room_control_status==PROCESSING` 的「回配」启发式判断——这是本次误显的根因（未最终确认的配房中订单会被误判成回配）。
3. 点击「回配」仍调既有接口（**未变**）：`POST /v3/admin/order/hotel-requirements/{requirementId}/reopen`（requirementId 取详情 `current.requirementId`，或直接用 `canReopen.endpoint` 提示的路径）。

## 已验证（测试服 API 实测）
- `GET /admin/house/orders/2071784830965620737`（house_status=CONFIRMED 且本人持有）→ `actions.canReopen = {enabled:true, code:"REOPEN", label:"回配", disabledReason:null, endpoint:".../reopen"}`。
- 未确认（配房中）/ 非本人持有 → `enabled=false` + 对应 `disabledReason`（单测覆盖）。
- 操作日志 opTypeLabel：`REOPEN` 现显示中文「回配」（原显示英文 REOPEN）。

## 同批后端修复（无需前端改动，告知即可）
本批 PR #4707 一并修了另外两项房务缺陷，**前端无需改**：
1. **房务主动给定制师发起会话 → 定制师端「联系房务」红点现会点亮**：原房务发起时消息落留言池、从不累加定制师未读，现已修（后端 `open-house` 以订单定制师为锚判定开会话方）。前端红点仍读原有 `unreadMessageCount`，**自动生效**。
2. **已完成配房（CONFIRMED）的订单不再滞留房务待办列表**：finalize 兜底 RESOLVE 相关待办 + 待办「定制师消息未读」派生项跳过已确认单。待办列表接口/字段**不变**。
