修改场次bug

findings.md

@@ -581,3 +581,15 @@
 - 查询参数按路由白名单投影；历史手机号查询只保留尾四位，其他自由查询只记录是否存在。
 - 账号名的 `username`、`display_name`、`created_by`、`requested_by` 等别名统一脱敏，UUID 形态用户名也不例外。
 - ResponseWriter 仅在底层实际支持时暴露 `http.Flusher`；已提交响应后发生 panic 时不再追加错误 JSON。
+
+# 2026-07-28 手机号查询返回重复排队号码
+
+- 用户截图显示手机号查询共返回 3 张排队单，其中同一项目“鸳鸯湖下湖（玻璃钢船）”出现两条 `00001`。
+- 两条记录的 `revision` 分别为 `1` 与 `3`，服务端时间也略有差异；这说明重复项来自后端查询结果，不是 React 对同一数组元素重复渲染。
+- 重复记录均为 `WAITING`，项目 ID 相同、号码相同，但当前公开 DTO 未返回 ticket ID 或 queue session ID；优先核查同一项目多个活动场次被同时查询的情况。
+- 已用真实 PostgreSQL 构造“同项目昨日/今日两个 `RUNNING` 场次，各有同手机号 `00001`”场景；`TestInternalPhoneLookupUsesLatestActiveSessionPerProject` 在修复前稳定返回两条，revision 分别为 `3` 与 `1`。
+- `queue_tickets` 已有 `(project_id, queue_session_id, display_number)` 和 `(project_id, queue_session_id, ticket_number)` 唯一约束，因此这不是同一场次内的重复写入。
+- `statusByPhone` 当前直接筛选所有状态为 `RUNNING/PAUSED` 的场次；员工队列和公屏快照则都按 `business_date DESC` 只选择最新活动场次，查询口径不一致是首要根因。
+- 根因已确认：跨营业日创建新场次时，旧场次可能仍保留 `RUNNING/PAUSED`；手机号查询没有像员工队列和公屏一样选择最新场次，因此把旧、新场次中的同号同时返回。
+- 修复在数据库查询层增加按项目关联的“最新活动场次”子查询，不采用结果数组去重；这样旧场次同号会被排除，当前场次中同手机号的 `00001`、`00002` 等合法不同号码仍全部返回。
+- 本次不需要数据库迁移，也不修改历史数据；重新发布 API 后查询立即按新口径生效。