二七王：S-8 curmultiple 改为带符号

问题：S-1 实现时取了绝对值，而判定的正负号恰恰是「谁赢」的区分——
3 大光 vs -3 升3级、2 小光 vs -2 升2级、1 过庄 vs -1 升1级，取绝对值后
三对完全撞在一起，D-8 的过程中判定动画无从分辨该播哪个。

改法：get_curmultiple 直接返回 get_upgrade 原值，与结算包 aset.upgrade
完全同口径（3/2/1 庄家大光/小光/过庄，-N 闲家升N级，0 叫分未定）。
顶部「抓分」角标只关心大小，取 Math.abs 即可；判定动画靠符号分辨，
前端一套映射通吃「过程中」与「结算前」两条路径。

协议 4 处 curmultiple 说明同步（shangzhuang / chupai1 / chupai2·3 /
PushCards）。

测试（hint 33 → 46 checks）：
- 钉住三对「绝对值相同、判定相反」的组合可区分，以及符号语义
  （>0 庄赢 / <0 闲赢 / ==0 叫分未定）。
- 新增一组【直接调 get_curmultiple 本身】覆盖负数分支，含爬坡 Q 分段。

补上一个测试盲点：第一次反向验证（把实现退回取绝对值）竟然全绿——因为
原有断言里算法层的 cm() 走的是 A.get_upgrade、绕过了 get_curmultiple，
而端到端那局恰好是大光(正数)，取不取绝对值都一样。补齐直接调用的用例后
再验，4 条断言立刻失败。

至此 §7.5 服务端待补 8 条全部完成，服务端侧无遗留；D-8 只差动画设计稿
与触发细节。

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

server/games/erqiwang/docs/protocol/packet_protocol.md

@@ -188,7 +188,7 @@
 | cards | 数组 | 拿了底牌后手上的牌（36 张，含底牌），庄家才有此属性，闲家没有该属性 |
 | countdown | 整数 | 选主倒计时 |
 | touxiang | 整数 | 是否允许投降 0：不允许 1：允许（仅 70 分坐庄为 1）。投降与选主互斥、同为选主阶段(step2)的决策，见 touxiang 包与 design §4 |
-| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：按此刻累计捡分实时算出的判定倍率**绝对值**（3 大光 / 2 小光 / 1 过庄 / N 升 N 级）。上庄时捡分恒为 0，故必为 3。供客户端顶部「抓分」列角标显示。三家同值（捡分本就公开），叫分未定时为 0。**不含扣底**——扣底要到末轮才产生 |
+| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：按此刻累计捡分实时算出的判定倍率，**带符号**，与结算包 `aset.upgrade` 同口径——`3`/`2`/`1` = 庄家 大光/小光/过庄，`-N` = 闲家升 N 级，`0` = 叫分未定。上庄时捡分恒为 0，故必为 `3`。三家同值（捡分本就公开）。**不含扣底**——扣底要到末轮才产生。<br>顶部「抓分」角标只关心倍数大小，取 `Math.abs` 即可；**符号供客户端的判定动画分辨该播哪个**（不能取绝对值，否则 3 大光与 -3 升3级会撞在一起）|
 
 ---
 
@@ -296,7 +296,7 @@
 | countdown | 整数 | 下一个出牌者的出牌倒计时 |
 | baozhu | 整数 | 是否已有玩家报无主（主牌出空）0否 1是；对应服务端 `have_baofu()`（任一玩家 `seatlist[seat][4][0]==0`）。**仅可查牌模式**下才可能为 1，是**余主公示**与"明牌"按钮的开关；**不查牌模式恒为 0**（design §9）|
 | cardsinhand | 数组 | 出牌者出牌后手上剩下的牌id列表，只有出牌者才有此属性 |
-| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：按当前累计捡分实时算出的判定倍率**绝对值**（3 大光 / 2 小光 / 1 过庄 / N 升 N 级）。与结算包 `aset.upgrade` 同源同算法，差别仅在此处**不含扣底**。三家同值，随本包下发、不另开推送 |
+| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：**带符号**，与结算包 `aset.upgrade` 同口径（`3`/`2`/`1` 庄家大光/小光/过庄，`-N` 闲家升 N 级，`0` 叫分未定）。同源同算法，差别仅在此处**不含扣底**。三家同值，随本包下发、不另开推送。符号是「谁赢」的区分，客户端判定动画靠它分辨 |
 | mustcard | 数组 | **下一个出牌者本轮跟牌的必出牌**（design §5.2），供其客户端自动选中。**只发给 `nextseat` 那一家**，其余两家无此属性——它是该玩家自己手牌的子集，整表下发会泄露他家手牌结构。以下情形不下发：`nextseat` 是本轮首家、首家为**甩牌**（甩牌跟牌走逐分量匹配，见 design §5.4.4）、或算出的必出牌为空 |
 
 ---
@@ -333,7 +333,7 @@
 | cardsinhand | 数组 | 出牌后出牌者手上剩下的牌id列表，只有出牌者才有此属性 |
 | maxseat | 整数 | 本轮出牌谁最大，只有本轮最后一个玩家出牌后才有此属性 |
 | grade | 整数 | 本轮闲家得分，只有本轮最后一个玩家出牌后且闲家有得分才有此属性 |
-| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：按当前累计捡分实时算出的判定倍率**绝对值**。与结算包 `aset.upgrade` 同源同算法，差别仅在此处**不含扣底**。三家同值，随本包下发、不另开推送 |
+| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：**带符号**，口径同 `aset.upgrade`。同源同算法，差别仅在此处**不含扣底**。三家同值，随本包下发、不另开推送 |
 
 ---
 
@@ -602,7 +602,7 @@
 | seatlist | 数组 | 三家座位牌况，与上文 chupai 包的 `seatlist` 同名同结构（每个玩家一个 5 元素数组：4 个花色的 `[无该花色,无对]` + 报副 `[剩余主牌数,剩余主对数]`）。**仅可查牌模式下有此属性**（design §9）|
 | liangpai | json | **亮牌**，结构同 maipai 包的 `liangpai`（`{ cards: [牌id...] }`）；**仅可查牌模式、且请求者为闲家、且庄家达标时有**（供闲家重连后仍能看到，design §8.2）|
 | pushlist | 数组 | 出牌历史 `[[[], [], []], [[], [], []], ...]`，外层下标=轮次（从第 1 轮起，含进行中的当前轮），内层**恒为 3 个数组**、按位置序号存该轮各家出的牌id，各自已按**本局主牌花色**从大到小排序。**仅可查牌模式下有此属性**——往轮打出、已被收走的牌属于「查牌」范畴，不查牌模式一律不下发（design §9）。注意当前这一轮桌面上的牌由 `playproc.cards` 恢复，**两种模式下都有**，否则后出的人无从跟牌 |
-| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：与 `chupai1/2/3` 同源同值，供重连后顶部「抓分」角标立即正确 |
+| curmultiple | 整数 | **当前抓分倍数**（design §7.2.0）：**带符号**，与 `chupai1/2/3` 同源同值，供重连后顶部「抓分」角标与判定动画状态立即正确 |
 | mustcard | 数组 | **本轮跟牌的必出牌**（design §5.2）。**仅当 `playproc.currseat == 请求者座位` 时才有**，且只算请求者自己的手牌；未轮到本家、本轮首家、甩牌局面、必出牌为空时均无此属性 |
 
 **Balance（不在结算阶段无此属性）**