二七王：实现 S-1 curmultiple 与 S-2 mustcard

S-1 当前抓分倍数（design §7.2.0）：
- class.paiju.js 新增 get_curmultiple()，复用 get_qvalue + get_upgrade，
  与结算 aset.upgrade 同源同算法，差别仅在不含扣底（末轮才产生）。
- 随现有包下发、不另开推送：shangzhuang / chupai1-3 / deskinfo.PushCards。
- 三家同值，整表下发不涉及泄露（捡分本就公开）；叫分未定时为 0。

S-2 跟牌必出牌（design §5.2）：
- class.paiju.js 新增 get_mustcard(seat)，内部复用与出牌校验完全相同的
  get_followcard，故建议与校验天然一致。
- 【只发给 nextseat 一家】：它是该玩家自己手牌的子集，整表下发会泄露
  他家手牌结构（server 红线：发全 ≠ 发多）。
- 四种情形不下发：非出牌阶段、该座位是本轮首家、首家甩牌、必出牌为空。
  甩牌一条尤其重要——甩牌跟牌走 flush_follow_ok 的逐分量匹配，与
  get_followcard 不是同一条路径，给建议会给错。

测试（新增 test/test_hint.js，33 checks）：
- curmultiple：算法层逐档对齐 design §7.2.0 判定表（含爬坡 Q 分段）、
  三家同值、重连与出牌包一致、叫分未定为 0、与 get_upgrade 绝对值一致。
- mustcard：只有 nextseat 收到、另两家没有、内容确属收包者自己的牌、
  首家无、缺门有富余时无、手牌数恰等于首家张数时整手必出、甩牌不发、
  非出牌阶段不发、重连按 currseat 门控。

过程中修正的两个测试自身问题（均为脚本缺陷，非业务缺陷，业务判定经证据核实正确）：
- 「缺门方无必出」原用例给闲2 只发 2 张牌，恰等于首家张数，get_followcard
  正确判定为「整手必出」；改为发 4 张才留出选择余地，并补一条对照用例
  锁住「恰等于张数则整手必出」这个正确行为。
- 「甩牌不发」「非出牌阶段不发」两条原本是假通过——桩的 startcount 仍是 -1，
  前置守卫先返回了 null，根本没测到被测因素。改为先把桩推进到跟牌态、
  每个用例只变动一个因素，并加一条「自证」用例确认推进后确实能算出必出牌。

另：mustcard 补进 test_leak.js 的 CARD_FIELDS 审计白名单（与 burycards 同理，
不加则误发不会被泄露审计发现）。反向验证：改成整表下发后，审计立刻报出
5 张越权牌；把 curmultiple 写死为 1 后，两条断言失败。均已还原、全绿。

协议文档同步 shangzhuang / chupai1-3 / PushCards 的字段说明。
至此 §7.5 服务端待补 5 条全部完成，服务端侧无遗留。

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

docs_dev/二七王-UI资源与精灵清单.md

@@ -1562,8 +1562,8 @@ codes/config/
 ## 7. 待补充清单
 
 > **状态汇总**（2026-08-25）：待确认规格 29 项**已全部有结论**（T-9 亮牌文案暂定 `x对 x主`；T-20 音效明确后续补充）。
-> **§7.5 服务端待补项**共 5 条：**S-4 / S-5 已完成**（字段拆分 + 三份文档术语统一），**S-3 已定论**（无需改服务端），
-> 剩 **S-1**（抓分倍数字段 `curmultiple`）与 **S-2**（下发应选中的牌 `mustcard`）待实现。
+> **§7.5 服务端待补项 5 条已全部完成**：S-1 `curmultiple`、S-2 `mustcard`、S-3（按手册、无需改服务端）、S-4 字段拆分、S-5 术语同步。
+> **服务端侧无遗留项**；前端开工只等美术与编辑器资源（§7.4）。
 
 ### 7.1 待出设计稿的界面（后续统一补充）
 
@@ -1604,13 +1604,13 @@ codes/config/
 | ~~T-6~~ | 叫分按钮**按档位位置固定三档配色**（浅黄/金黄/橙）+ 灰=已叫过；按钮底与角标底各 4 帧（§1.3） |
 | ~~T-7~~ | 选主按钮中央大数字 = 该花色**张数**，右上角标 = 该花色**对数**（§1.5） |
 | ~~T-8~~ | 手牌标记 3 帧：`拖`=拖拉机 / 橙星=**正2正7** / 蓝星=**其他主牌**；前端据 `flower` 本地标注（§1.6） |
-| ~~T-10~~ | 出牌阶段**必有** `提示` 按钮；另需服务端下发「应选中的牌」以实现自动选中 → **S-2** |
+| ~~T-10~~ | 出牌阶段**必有** `提示` 按钮；服务端已下发 `mustcard` 供自动选中（S-2 ✅） |
 | ~~T-11~~ | 牌型标签**只做「毙」一种**；数据层保留 毙/垫/混合出牌 三种标识备扩展，当前不出图 |
 | ~~T-12~~ | `底牌 20x0` 的 `x` 后面是**扣底倍数**（`bottom.multiple`）；未扣底显示 0（§1.8） |
 | ~~T-13~~ | 结算两个小字 = `牌局分`(`grade_jf`) / `算奖分`(`grade_aw`) |
 | ~~T-14~~ | 算奖明细走独立的**算奖牌型叠加层** |
 | ~~T-15~~ | 准备标识**用平台的** |
-| ~~T-16~~ | `抓分` 角标 = **当前捡分对应判定倍率的实时预览**（大光×3/小光×2/过庄×1/升N级×N）；协议现无此字段，需服务端随现有包下发 → **S-1** |
+| ~~T-16~~ | `抓分` 角标 = **当前捡分对应判定倍率的实时预览**；服务端已下发 `curmultiple`（S-1 ✅） |
 | ~~T-17~~ | 倒计时归零**停在 `0`** 不隐藏 |
 | ~~T-18~~ | 底栏 5 按钮：`上一轮`/`出牌历史`/`明牌`/`扣底`(看**埋牌底牌**)/`底牌`(看**底牌**)；术语已统一见 §2.6；可见性按手册 → **S-3** |
 | ~~T-19~~ | 数字**一律用图片多帧精灵**（参考图数字带描边渐变，文字精灵做不出），资源 631–634 全部要出 |
@@ -1675,56 +1675,44 @@ codes/config/
 
 以下 3 条来自本轮确认的需求，**当前协议/服务端不支持**，需在服务端补齐后前端才能实现。三条都要同步更新 `packet_protocol.md`。
 
-#### S-1 · 「当前抓分的倍数」字段（对应 T-16）—— 语义已确认，待服务端实现
+#### S-1 · 「当前抓分的倍数」字段 `curmultiple` —— ✅ 已完成（2026-08-25）
 
-**需求**：顶部信息条 `抓分` 列的角标显示「当前抓分的倍数」（参考图 `45 [1倍]`），且**牌局过程中可见并正确更新**。
+**语义**：当前捡分对应判定倍率的**实时预览**——「若此刻结束是几倍」，取绝对值。
 
-**语义（已确认）**：**当前捡分对应的判定倍率的实时预览**——即「若此刻结束，是几倍」：
-
-| 当前捡分 `grade` 相对叫分 `call` | 判定 | 倍率 |
+| 当前捡分 `grade` 相对叫分 `call` | 判定 | `curmultiple` |
 | --- | --- | --- |
-| `grade == 0` | 庄家：大光 | **×3** |
-| `0 < grade < Q` | 庄家：小光 | **×2** |
-| `Q ≤ grade < call` | 庄家：过庄 | **×1** |
-| `grade ≥ call` | 闲家：升 N 级 | **×N** |
+| `grade == 0` | 庄家：大光 | **3** |
+| `0 < grade < Q` | 庄家：小光 | **2** |
+| `Q ≤ grade < call` | 庄家：过庄 | **1** |
+| `grade ≥ call` | 闲家：升 N 级 | **N** |
 
-（`Q` = 小光/过庄分界兼升级级距：常规算子固定 40，爬坡按叫分分段，见 design §7.2.0 / §7.3.2。）
+（`Q` = 小光/过庄分界兼升级级距，常规算子固定 40、爬坡按叫分分段，design §7.2.0 / §7.3.2。）
 
-**现状**：服务端**没有任何**下发此值的字段。`chupai1/2/3` 只带 `grade`（本轮闲家得分），倍数类字段（`aset.upgrade`、`bottom.multiple`）**都要到结算包才有**。
+**下发位置**（随现有包，**不另开推送**）：`shangzhuang`、`chupai1`、`chupai2`、`chupai3`、`deskinfo.PushCards`。
 
-**实现要求**：
+**要点**：
+- 三家**同值**，整表下发不涉及泄露（`grade` 本就公开）。
+- 与结算包 `aset.upgrade` **同源同算法**（`get_qvalue` + `get_upgrade`），差别只在这里**不含扣底**——扣底要到末轮打完才产生。
+- 叫分未定时为 **0**，前端不显示角标。
+- 前端**不得自算**（服务端权威）。
 
-1. 算法**已存在**：`class.arith.js` 的 `get_upgrade(call, grade, q)` 返回带符号判定倍率（3 大光 / 2 小光 / 1 过庄 / −N 升 N 级），出牌过程中随时可算。
-2. **不新开推送包**——随现有包一起下发，避免多一条推送链路：
+**实现**：`class.paiju.js` 新增 `get_curmultiple()`；`mod.js` / `class.export.js` 组包处下发。
 
-| 包 | 增加字段 | 类型 | 说明 |
-| --- | --- | --- | --- |
-| `chupai1` / `chupai2` / `chupai3` | `curmultiple` | 整数 | 按当前累计捡分实时算出的判定倍率**绝对值**（`Math.abs(get_upgrade(...))`） |
-| `deskinfo.PushCards` | `curmultiple` | 整数 | 同上，供重连后立即正确显示 |
-| `shangzhuang` | `curmultiple` | 整数 | 叫分刚定、`grade == 0` 时即为大光 ×3，需要一个初始值 |
+#### S-2 · 下发「应当选中的牌」`mustcard` —— ✅ 已完成（2026-08-25）
 
-3. 三家**同值**，可整表下发，不涉及泄露（`grade` 本来就是公开信息）。
-4. 前端**不得自算**——判定倍率属服务端权威裁定（红线：服务器权威、前端只显示不自算）。
+**语义**：下一个出牌者本轮跟牌的**必出牌**（design §5.2），前端收到后自动选中（上浮），玩家确认后点 `出牌`。
 
-#### S-2 · 下发「应当选中的牌」（对应 T-10）
+**下发位置**：`chupai1` / `chupai2`（给 `nextseat`）、`deskinfo.PushCards`（给轮到的那一家）。
 
-**需求**：某些情况下（跟牌存在必出牌、或唯一合法出法）服务端下发应选中的牌，前端收到后自动选中。
+**可见性（关键）**：**只发给 `nextseat` 一家**。它是该玩家自己手牌的子集，发给他本人不泄露；**整表下发会把另两家的手牌结构透露出去**（server 红线：发全 ≠ 发多，按可见性下发）。已纳入 `test_leak.js` 的 `CARD_FIELDS` 审计白名单。
 
-**现状**：`chupai1/2/3` 下发包里没有此字段。
+**不下发的情形**：
+1. 非出牌阶段；
+2. 该座位是本轮**首家**（自由出牌，无必出）；
+3. 首家是**甩牌**——甩牌跟牌走 `flush_follow_ok` 的逐分量匹配（design §5.4.4），与 `get_followcard` 不是同一条路径，给建议会给错，宁可不发；
+4. 算出的必出牌为空（玩家可自由选）。
 
-**好消息——算法已存在，只差下发**：`class.arith.js:737` `get_followcard(mainflower, inhandcards, startcount, startflower, startcardtype)` 已经返回
-
-```
-{ mustcard: 必出的牌列表, cancard: 可出的牌列表, cantype: 可出牌需要的牌型 }
-```
-
-目前只在 `class.arith.js:1055` 用于内部合法性校验，**从未下发**。建议在 `chupai1/2/3` 里**按座位差异化**下发给「下一个出牌者」：
-
-| 字段 | 类型 | 说明 |
-| --- | --- | --- |
-| `mustcard` | 数组 | 该座位本轮的必出牌 id 列表；**只发给 `nextseat` 对应的那一家**，其他两家不带 |
-
-**下发面注意**（红线：发全 ≠ 发多）：`mustcard` 是**该玩家自己手牌**的子集，只发给他本人不泄露任何信息；**绝不可整表下发三家的 `mustcard`**——那等于把另两家的手牌结构透露出去。
+**实现**：`class.paiju.js` 新增 `get_mustcard(seat)`，内部复用**与出牌校验完全相同**的 `get_followcard`，故建议与校验结果天然一致。
 
 **不违反「请求包只带意图」**：方向是服务端 → 前端的建议，前端仍只回传 `cards`，合法性最终由服务端校验。