二七王：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/class.paiju.js

@@ -830,8 +830,8 @@ var cls_youle_erqiwang_paiju = cls_youle_erqiwang_paiju || {
 		return re;
 	},
 
-	//当前抓分倍数（design §7.2.0）：按【当前累计捡分】实时算出的判定倍率绝对值，
-	//供客户端顶部「抓分」列角标显示「若此刻结束是几倍」。
+	//当前抓分倍数（design §7.2.0）：按【当前累计捡分】实时算出的判定倍率，【带符号】。
+	//供客户端顶部「抓分」列角标显示「若此刻结束是几倍」，以及对局中的判定动画（D-8）。
 	//与结算包 aset.upgrade 同源同算法（get_qvalue + get_upgrade），差别只在：
 	//这里的捡分【不含扣底】——扣底要到最后一轮打完才产生，出牌过程中尚不存在。
 	//叫分未定（call<=0）时返回 0，前端不显示角标。
@@ -843,8 +843,13 @@ var cls_youle_erqiwang_paiju = cls_youle_erqiwang_paiju || {
 		var _cfg   = cls_youle_erqiwang_config.parse(o_paiju.o_desk.o_room.roomtype);
 		var _grade = cls_youle_erqiwang_paiju.get_jian_grade(o_paiju).grade;
 		var _q     = cls_youle_erqiwang_arith.get_qvalue(_call, _cfg.climb);
-		var _u     = cls_youle_erqiwang_arith.get_upgrade(_call, _grade, _q);
-		return (_u < 0) ? (0 - _u) : _u;
+		//【带符号】返回，与结算包 aset.upgrade 完全同口径：
+		//  正数 3/2/1 = 庄家 大光/小光/过庄；负数 -N = 闲家升 N 级。
+		//符号就是「谁赢」的区分，不能取绝对值——否则 3(大光) 与 -3(升3级)、
+		//2(小光) 与 -2(升2级)、1(过庄) 与 -1(升1级) 三对会完全撞在一起，
+		//客户端的判定动画将无从分辨该播哪个（前端清单 S-8）。
+		//只关心倍数大小的用途（如顶部「抓分」角标）自行取绝对值即可。
+		return cls_youle_erqiwang_arith.get_upgrade(_call, _grade, _q);
 	},
 
 	//某座位本轮跟牌的「必出牌」（design §5.2），供客户端自动选中。