二七王：重新生成夹具、BuryHandler 接住 maipai.playproc，修正甩错断言的错误映射

配合上一个 commit 服务端补发的 maipai.playproc，重新生成真包夹具（diff 只新增
三家 maipai 包各一份 round-1 初值 playproc，无其他变化）后跑一致性测试，暴露出
前端还有一处对应缺口：BuryHandler.js 组 table.playproc 时没有接 data.playproc
（PlayHandler.js 早已对 chupai1/2/3 做了同样的原样拷贝），于是「埋牌完成→庄家
首出」窗口增量路径的 table.playproc 停在上一阶段的 null。现补上，并在
test_handlers_bury.js 新增一条用例守住、用「退回修复必转红」反向验证。

test_handlers_play.js:84 的 `S.table.playproc.shuaicuo` 断言的正是此前 Fix Round 2
裁决②（本手信息收进事件载荷、不进 GameState）判定为缺陷的旧映射，playproc 改为
原样拷贝服务端结构后必然读 null 硬崩。按 task-12d-report.md §8 的裁决与建议替换：
断言改为守事件载荷（EQW_CARD_PLAYED 的 shuaicuo/order/seat/cards/count/flower/
cardtype）+ playproc 原样拷贝，强度不降——原断言只守住"甩错标志被处理"这一件事，
新断言额外多守了"本手信息不得混入 playproc"一条。

client/tests/test_consistency.js 全绿（23 checks，此前 20 绿/3 红）；
client/tests/run.js 全绿（20 脚本）；server/games/erqiwang/test/run.js 全绿
（17 脚本/675 checks，见上一个 commit）。

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

client/tests/test_handlers_bury.js

@@ -55,4 +55,18 @@ S.reset();
 EQW_BuryHandler.handle({ success: true, seat: 0, countdown: 20 });
 t.eq('无亮牌时保持 null', S.table.liangpai, null);
 
+// playproc：埋牌完成时服务端已就地开好 round-1 的进行态，恒有、原样拷贝进 table.playproc，
+// 与 chupai1/2/3.playproc 同源同结构（协议 §9），漏接会让「埋牌完成→庄家首出」这段窗口
+// 增量路径 table.playproc 停在上一阶段的 null、与重连路径不一致
+S.reset();
+EQW_BuryHandler.handle({ success: true, seat: 0, countdown: 20, cards: [1, 2, 3],
+                         burycards: [9, 10, 11, 12, 13, 14, 15, 16],
+                         playproc: { round: 1, start: 0, currseat: 0, startcount: -1,
+                                     startflower: -1, starttype: -1, maxseat: -1, maxcard: -1,
+                                     cards: [null, null, null], shuai_demand: null } });
+t.eq('埋牌 playproc 原样拷贝服务端本轮进行态', S.table.playproc, {
+    round: 1, start: 0, currseat: 0, startcount: -1, startflower: -1, starttype: -1,
+    maxseat: -1, maxcard: -1, cards: [null, null, null], shuai_demand: null
+});
+
 process.exit(t.done('handlers_bury') ? 0 : 1);