fix(changelog): 订正 8152 交接件 vehicle-households 端点 statusName 编造取值

`three` 处示例/字段说明里的 statusName 中文值（"已完成"/"待处理"）系凭空编造，既不是修复前的房务口径值（"配房完成"/"待房务配"），也不是修复后的车务口径值。核对 GroupBatchConverter.resolveRequirementStatusName(code, true) 源码后改为实测口径：PENDING→待车队配、PROCESSING→配车中、DONE→配车完成。

同时订正 六.5 枚举表里同样错误的三个取值，并补一段说明——该端点 statusName 原实现直接取 RequirementStatus 枚举的房务侧 label，已由 45adfd7ed（PR #8173）改调 resolveRequirementStatusName(code, true) 修正，附完整取值表。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

changelogs-v2/2026-09/22_8152_团期用车需求补车辆规格与接送机汇总-修改接口-管理后台.md

@@ -420,7 +420,7 @@ Authorization: Bearer <token>
 | requirements[].kind | String | `TRAVEL` = 行程用车 / `TRANSFER` = 接送机 |
 | requirements[].kindName | String | 类别中文名，后端下发，前端不自己映射 |
 | requirements[].status | String | PENDING_REVIEW / PENDING / PROCESSING / DONE |
-| requirements[].statusName | String | 状态中文名；状态为空或无对应枚举时为 null |
+| requirements[].statusName | String | 状态中文名（车务口径）；`status` 为空时为 `null`，遇未知状态码时原样回落该 code 字符串 |
 | requirements[].fleet | Array&lt;FleetItem&gt; | 车队明细，定制师所报原貌，不做合并 |
 | requirements[].specialTags | Array&lt;SpecialTagItem&gt; | 特殊诉求标签；未填为空列表 |
 | requirements[].remark | String | 备注 / 其他诉求，≤500；未填为 null |
@@ -474,7 +474,7 @@ Authorization: Bearer <token>
             "kind": "TRAVEL",
             "kindName": "行程用车",
             "status": "DONE",
-            "statusName": "已完成",
+            "statusName": "配车完成",
             "fleet": [
               { "vehicleType": "suv", "vehicleTypeName": "SUV系列", "seats": 7, "count": 1 }
             ],
@@ -494,7 +494,7 @@ Authorization: Bearer <token>
             "kind": "TRANSFER",
             "kindName": "接送机",
             "status": "PENDING",
-            "statusName": "待处理",
+            "statusName": "待车队配",
             "fleet": [
               { "vehicleType": "mpv", "vehicleTypeName": "商务车", "seats": 7, "count": 1 }
             ],
@@ -560,6 +560,20 @@ Authorization: Bearer <token>
 - `countedInSummary=false` 在本端点的含义是「该户没有活跃 TRAVEL 行」——典型就是只报了接送机的户。车侧汇总只统计行程用车。
 - `pickupRequired` / `dropoffRequired` 仅 TRANSFER 行有意义，TRAVEL 行上为 null。
 - 不传 `kind` = 两类都返，这与提交侧「不传按 TRAVEL」的缺省相反：只读筛选若沿用提交侧缺省，接送机会整类从页面消失且无提示。
+- 🔴 **`statusName` 口径订正说明（曾误用房务枚举 label）**：本端点的 `statusName` 原实现直接取 `RequirementStatus` 枚举自带的 `label`——该枚举被房、车两域共用，`label` 是**房务侧视角**文案（`PENDING` 的 label 字面量就是「待房务配」），枚举类自己的 javadoc 已写明「车需求场景下的展示文案由前端另行映射」。已由 `45adfd7ed`（PR #8173，`fix(order-v3): 用车逐户需求读口 statusName 改用车务文案，不再吐枚举的房务 label (#8151)`）修正为改调 `GroupBatchConverter.resolveRequirementStatusName(code, true)`，与团期其它用车读口（团级正式需求的 `vehicleRequirementStatusName` 等）同一口径。完整取值：
+
+| `status` | `statusName`（车务口径） |
+|------|------|
+| `PENDING` | 待车队配 |
+| `PROCESSING` | 配车中 |
+| `DONE` | 配车完成 |
+| `PENDING_REVIEW` | 待审核 |
+| `REJECTED_TO_CONSULTANT` | 已驳回定制师 |
+| `REJECTED_TO_ADMIN` | 已驳回管理员 |
+| 其它未知码 | 原样回落该 code 字符串 |
+| 空 / `null` | `null` |
+
+  后两个驳回态在映射范围内，但被打回的需求行已失活、不出现在本端点的列表里（见前一条），故本列表实际只会出现前 4 行。
 
 ---
 
@@ -872,11 +886,11 @@ query 参数不传 = 两类都返。
 | 值 | 中文 | 说明 |
 |----|------|------|
 | `PENDING_REVIEW` | 待审核 | 定制师已提交，等团期侧核对 |
-| `PENDING` | 待处理 | 已进入处理队列 |
-| `PROCESSING` | 处理中 | 车务作业中 |
-| `DONE` | 已完成 | 本需求行已闭环 |
+| `PENDING` | 待车队配 | 已进入处理队列 |
+| `PROCESSING` | 配车中 | 车务作业中 |
+| `DONE` | 配车完成 | 本需求行已闭环 |
 
-被打回的需求行已失活，不出现在本端点的列表里；`statusName` 在状态为空或无对应枚举时为 `null`。
+被打回的需求行已失活，不出现在本端点的列表里；`statusName` 是车务口径中文名（见上表），`status` 为空时为 `null`，遇未知状态码时原样回落该 code 字符串。
 
 ### specialTags（字典 `vehicle_special_demand`）