二七王：S-7 明牌条件按手册定案，服务端无需改动

结论：按 design §9.3——任一玩家报无主后，三家都显示「明牌」按钮，
且整个出牌阶段随时可查、不限次数。判定依据是「场上有人报无主」而非
「自己报无主」，报无主那位和另外两位一样能看。

此前我把前端条件收紧成「自己是无主玩家」，比手册严格，反而与服务端
have_baofu() 的受理条件对不上。现改回：

- 前端清单 §1.7 D-6、§2.6 底栏按钮、§0.0 对照表、baozhu 字段说明统一为
  「可查牌 + 出牌阶段 + baozhu==1 → 三家都显示」。
- design §9.3 第 3 条补一句消歧：明确「为这三个人都出现」、判定依据是
  场上有人报无主、且不限次数随时可查。原文靠「同时」承接上一条的
  「为全体三人」，容易读漏。
- protocol 的术语表与 mingpai 受理条件说明同步加注。

服务端与协议本来就是手册口径，无代码改动。此前记的「有主牌玩家伪造请求
也能拿到明牌数据」这一泄露担忧不成立——按手册他本就有权查看，服务端受理
是正确行为。

验收清单增至 18 条，新增一条专门钉住「三家都显示，不是只给自己无主那家」。
至此 §7.5 服务端待补项 7 条全部处理完毕，服务端侧无遗留。

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

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

@@ -31,7 +31,7 @@
 | --- | --- | --- | --- | --- |
 | **亮牌** | 庄家 → 两个闲家 | **具体牌面**（庄家全部固定主牌） | 庄家埋牌后固定主牌达门槛（design §8.2） | `liangpai.cards` |
 | **余主公示** | 全体 → 全体 | **只有数量**（剩余主牌数、主对数） | 任一玩家报无主（design §9） | `seatlist[seat][4]`、`baozhu` |
-| **明牌** | 他家 → 请求者 | **具体牌面**（他家全部未出主牌） | 可查牌 + 报无主，主动点击（design §9） | `mingpai.others[].zhucards` |
+| **明牌** | 他家 → 请求者 | **具体牌面**（他家全部未出主牌） | 可查牌 + **任一**玩家报无主 → **三家均可点、随时可查**（design §9） | `mingpai.others[].zhucards` |
 | **开底** | 桌面 → 所有玩家 | **具体牌面**（8 张底牌） | 70 分坐庄，**摸底之前** 3 秒（design §4） | `ancard3s` + `bottomcards` |
 
 一句话记：**只有「余主公示」是统计类（给数字），「亮牌」「明牌」「开底」都给具体牌面**——区别在给谁的牌：亮牌给庄家自己的、明牌给他家的、开底给桌上那 8 张。
@@ -341,7 +341,7 @@
 
 发包者：游戏　收包者：服务器　app：youle　route：erqiwang　rpc：mingpai
 
-查看另外两家手中全部主牌的具体牌面（design §9）。服务端仅在**可查牌模式、出牌阶段(step5)、且已有玩家报无主**（`have_baofu()`）时受理；不满足时按 0.2 回 `mingpai` 失败包（不查牌 / 未报无主 → `RULE`，非出牌阶段 → `STEP`）。
+查看另外两家手中全部主牌的具体牌面（design §9）。服务端仅在**可查牌模式、出牌阶段(step5)、且已有【任一】玩家报无主**（`have_baofu()`）时受理——注意判定的是「场上有人报无主」而非「请求者本人报无主」，报无主那位与另外两位同样有权查看（design §9.3）；不满足时按 0.2 回 `mingpai` 失败包（不查牌 / 未报无主 → `RULE`，非出牌阶段 → `STEP`）。
 
 | 参数名 | 类型 | 说明 |
 | --- | --- | --- |