二七王：maipai 补发 playproc（增量路径与重连路径对齐）

前端一致性测试剩余 3 红的根因：do_burycard() 内部已调 new_playround 初始化好
round-1 的进行态，但 mod.js 组 maipai 包时没有放 playproc（协议 §9 字段表也没有），
「埋牌完成 → 庄家首出」这段窗口增量路径 table.playproc 为 null，重连路径却已有初值——
与上一个 commit（8452535）给 maipai 补 seatlist 是同一个窗口、同一条理由，被漏在了同一处。

修法：复用既有的 get_playproc() 快照函数（与 chupai1/2/3、PushCards.playproc 同源，
本身就是逐字段深拷贝，不引入活引用风险）。可见性：此刻一张牌未出，round/start/currseat
等全部由桌面公开信息推出，cards 全空、shuai_demand 为 null，不含私密信息，故与
chupai1/2/3.playproc 一样三家整体下发、不受查牌模式门控。

协议文档 §9 同步补字段说明。test_rpc.js 新增 5 checks：庄闲同值、与重连快照比对、
round-1 初值断言、不查牌模式下仍恒有、深拷贝守卫；已用「退回修复必转红」反向验证
（3/5 转红）。既有 121 checks 未改一条断言，全绿（17 脚本 / 675 checks）。未涉及 shared/。

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

server/games/erqiwang/mod.js

@@ -331,6 +331,13 @@ youle_erqiwang.maipai = function(pack){
 		//全场公示的余主数量（design §9 明确要求向全体三人展示），故三家整表下发不构成泄露
 		msg.data.seatlist = o_paiju.seatlist;
 	}
+	//本轮进行态（design §5.1）：do_burycard 内部已调用 new_playround 就地初始化好了 round-1
+	//的进行态，与重连包 PushCards.playproc 同一个快照函数、同一结构（三家无差别）。
+	//没有它，「埋牌完成 → 庄家首出」这段窗口内增量路径的 table.playproc 是 null，
+	//重连路径却已有 round-1 初值，两条路径不一致。可见性：round/start/currseat 等全部
+	//由桌面公开信息推出，cards 此刻全空、shuai_demand 为 null，不含任何私密信息，
+	//与 chupai1/2/3.playproc 一样三家整体下发、不逐座位裁剪。
+	msg.data.playproc = cls_youle_erqiwang_paiju.get_playproc(o_paiju);
 	//埋牌底牌（本次埋下的 8 张）：取服务端权威快照，【不回显客户端提交的 cards 原序】。
 	//get_burycard 与重连包 PushCards.burycards 是同一个函数、同一套按本局主牌花色的排序，
 	//两条路径因此顺序一致（SSOT）；直接回显 cards 会把客户端的选牌顺序当成下发顺序。