# 配房选酒店候选数量修复（CORE 产品不再被截到 10 家）

> 变更类型：🔧 修复（后端，**前端一般无需改，仅候选数量变多**）
> 端类型：管理后台（房务管家·配房选酒店）
> 日期：2026-06-24 ｜ 工单：无（每日代码审查批量修复）｜ PR：#4369 ｜ 服务：hl-order-service-v3（已部署 health UP，网关实测）

---

## 背景
每日代码审查发现：配房「选择酒店」候选接口 `GET /v3/admin/hotel-candidates` 此前对 **CORE（核心订单）产品**内部被截断到最多 **10 家**，CUSTOM/团期最多 20 家——使 #4346/#4364「默认不按城市、列全部在售、取前 N」对 CORE 实际只返 10 家，`limit` 参数（默认 30、上限 50）不生效。

## 修复（已上线）
候选列表截断改为**单一真源**：以请求 `limit`（默认 30、上限 50）为准，不再被内部固定上限（10/20）提前截断。
- 排序逻辑不变：定制师点名 > 池内 > 普通（`isConsultantRecommended` / `isPoolMatch` 标签照常返回）。
- 现在 CORE 产品也能返回最多 `limit`（默认 30）家候选，与 CUSTOM/团期口径统一。

## 前端配合
- **一般无需改**：字段不变，仅候选条数可能变多（CORE 之前最多 10、现在最多 30）。
- 若前端列表有「只展示前 N」的本地硬编码，可放开到后端 `limit` 口径（默认 30）。

## 说明（本 PR 其余为内部加固，无前端影响）
同 PR #4369 还修了一批内部问题（不影响前端契约）：车队派单占位并发守卫（防孤儿占用）、配房段预算取最高协议价口径、§13.8 车务回写归属校验、错误码/注释规范等。

## 验证
- order-v3 全量 4466/0/0、fleet 全量 1304/0/0（含架构门禁）全绿；两服务部署双实例 health UP，网关实测服务可达。