fix(scratch): 补回 rekey 操作员缺失的门店分配，修好商户端登录

yeg

2026-09-17 9867d70e287a1bf7c734b84c59e0a24b1aca8dcd

fix(scratch): 补回 rekey 操作员缺失的门店分配，修好商户端登录

rekey 只改了 merchant_operator 一张表，门店分配在 merchant_operator_store（按 operator_id 关联），
于是换到 37/38/39 的三个登录账号（631/632/633）名下没有门店：登录能过密码校验，却报「当前账号未
分配可操作门店」。核销记录 verify_record.staff_id 同样还写着本机旧 id 10/34，在服务器上会算到别的
操作员头上。

已在服务器库执行 fix-operator-store-assignment.sql：
- 补门店分配 37→572、38→573、39→574（门店归属与状态先核对过）；
- 631/632 名下核销记录的 staff_id 改为 37/38。

验收：登录用的同一段 SQL 对三个 operator 都能查到门店行；三个账号的 operator.status / merchant.status
/ can_login_merchant_app 均为 1 且未锁定，密码 hash 未动（用户实测密码是过的，报错发生在密码校验之后）。
协议接受记录不搬（两库版本号口径不同，登录会按当前版本自动补记）；审计日志里的旧 id 属历史归属，
需要时再单独判读。README 补记该连带缺口。

 .scratch/db-merge/README.md

@@ -102,3 +102,22 @@
**两库从此对同一个人的 talent_id 不同（本机 446 / 服务器 1031），不要再做双向合并**——这正是下面
那条结论的实例。带 id 撞车的表不止这两处（`merchant_operator` 26 行、`merchant_agreement_acceptance`
28 行、`talent_card` 4 行两库内容不同），要长期可用只能选一个库作为唯一事实源。

## 2026-09-17 补：rekey 的连带缺口（商户登录）

`--rekey` 当时只改了 `merchant_operator` 一张表，而**门店分配在 `merchant_operator_store`**
（按 operator_id 关联）→ 换到 37/38/39 的三个登录账号名下没有门店，登录能过密码校验却报
「当前账号未分配可操作门店」。同理，核销记录 `verify_record.staff_id` 还写着本机旧 id 10/34，
在服务器上会算到别的操作员头上。

已执行 `fix-operator-store-assignment.sql`：补 37→572、38→573、39→574 三条门店分配，
并把 631/632 名下核销记录的 staff_id 改成 37/38。

验收：登录用的那段 SQL（`merchant_operator_store` join `merchant_store`）对 37/38/39 都能查到行；
三个账号的 operator.status、merchant.status、can_login_merchant_app 均为 1、未锁定。登录应可正常。

两处刻意不动：协议接受记录（服务器版本号 1.0.0、本机 v1.0，照搬会多出对不上的行；登录会自己补记）、
审计类日志（`merchant_login_audit` / `*_operation_log` 里可能仍有旧 id，属历史归属）。

另注：服务器上别的商户（如 90 测试影城）的操作员也没有门店分配——不是这次造成的（合并只插不改），
但那种账号同样会撞这条校验。

 .scratch/db-merge/fix-operator-store-assignment.sql

New file
@@ -0,0 +1,32 @@
-- 补回被 rekey 的操作员所缺的门店分配（只在服务器库执行）。
--
-- 为什么会有这个洞：合并时本机 operator 10/34/35（商户 631/632/633 的登录账号）与服务器同 id 撞车，
-- 用 --rekey 换成了新 id 37/38/39 —— 但 merchant_operator_store 是按 operator_id 关联的另一张表，
-- rekey 只处理了 merchant_operator 一张表，映射行没跟着换，于是三个账号都能过密码校验、却卡在
-- 「当前账号未分配可操作门店」（登录要求 os.operator_id 至少连到一个 status=1 的门店）。
-- 另外核销记录的 staff_id 还写着本机的旧 id，在服务器上会算到别的操作员头上。
--
-- 执行前确认门店归属（应为 572→631、573→632、574→633，status=1 deleted=0）：
select id, merchant_id, store_name, status, deleted from merchant_store where id in (572, 573, 574);

start transaction;

insert into merchant_operator_store(operator_id, store_id) values (37, 572), (38, 573), (39, 574);

-- 核销记录的归属：本机 staff_id 10/34 在服务器上属于别的操作员（商户 99 / 90）
update verify_record set staff_id = 37 where merchant_id = 631 and staff_id = 10;
update verify_record set staff_id = 38 where merchant_id = 632 and staff_id = 34;

commit;

-- 验收（三条都应有行，且门店属于对应商户）：
--   select os.operator_id, os.store_id, s.merchant_id, s.store_name
--   from merchant_operator_store os join merchant_store s on s.id = os.store_id
--   where os.operator_id in (37, 38, 39) order by os.operator_id;
--   select merchant_id, staff_id, count(*) from verify_record where merchant_id in (631, 632) group by merchant_id, staff_id;
--
-- 不在本脚本内处理的两件事：
--   * 协议接受记录（merchant_agreement_acceptance）不搬：服务器用的版本号是 1.0.0、本机是 v1.0，
--     照搬会多出一批版本号对不上的行；登录流程本身会按当前版本自动补记（MerchantAuthService）。
--   * 审计类日志（merchant_login_audit / operation_log / *_operation_log）里可能仍有本机旧 id 的行，
--     属历史归属问题，不影响登录与业务，需要时再单独判读。