feat: 实现最小正式版过水不胡规则并完善前端动作面板

- 后端实现最小正式版过水不胡规则：玩家在响应窗口选择PASS后，直到下次摸牌前不能响应胡
- 完善GameSeat状态管理，新增passedHuBlocked字段及相关方法
- 在ResponseActionWindowBuilder和GameActionProcessor中增加过水不胡校验
- 前端重构动作面板，区分回合动作和响应动作，支持多用户视角切换
- 优化公共事件处理逻辑，自动清理失效的私有动作面板
- 更新相关文档说明当前实现的规则范围和工程取舍
- 补充测试用例验证过水不胡规则的正确性

docs/RESPONSE_RESOLUTION_RULES.md

@@ -22,19 +22,22 @@
 - AI 与真人使用同一套优先级规则
 - 同优先级冲突时，按出牌者之后的最近顺位优先
 - `PASS` 仅表示放弃当前窗口，不等于永久放弃后续所有同类机会
-- `过水不胡` 作为后续增强规则，不在当前 `V1` 强制启用
-- `一炮多响` 在项目 `V1` 中暂不实现，采用“单窗口单胜出动作”的工程裁决
+- `过水不胡` 已在项目 `V1` 中启用“最小正式版”
+  - 玩家在响应窗口里本可 `HU` 但选择 `PASS` 后，直到自己下一次摸牌前，不能再做响应胡
+  - 该限制只作用于响应胡，不影响 `PENG / GANG`，也不影响自摸胡
+- `一炮多响` 已在项目 `V1` 中实现，但只对 `HU` 开放多赢家同窗裁决
+  - `PENG / GANG` 仍保持单赢家裁决，顺位规则不变
 
 ### 1.2 为什么这样定
 
 - 这样能和当前后端结构最自然衔接
-- 可以先把响应窗口停顿与恢复流程做稳
-- 避免在 `HU` 判定、多人同时胡牌、结算分摊都未稳定时，提前引入高复杂度冲突逻辑
+- 可以先把响应窗口停顿、恢复和结算主链做稳
+- 即使已支持一炮多响与最小版过水不胡，也仍把复杂度限制在当前统一动作入口和统一响应窗口内
 
 这符合：
 
-- `KISS`：先做单窗口单胜出
-- `YAGNI`：当前不抢做一炮多响和完整过手胡体系
+- `KISS`：一炮多响只对 `HU` 放开，多赢家共用一张牌源，避免把 `PENG / GANG` 也做成多胜出分支
+- `YAGNI`：当前不抢做完整地方化 `过水不胡` 体系，也不引入可配置规则模式层
 - `SOLID`：先把规则澄清文档与裁决器边界固定
 - `DRY`：所有动作冲突统一走一套优先级裁决
 
@@ -75,11 +78,10 @@
 
 - 某玩家打出一张牌后
 - 其他仍在牌局中的玩家基于这张弃牌触发响应窗口
+- 补杠声明后的抢杠胡响应窗口
 
 `V1` 暂不实现：
 
-- 抢杠胡窗口
-- 补杠后二次响应窗口
 - 最后一张牌必须胡的特殊强制窗口
 - 多轮连续嵌套响应窗口
 
@@ -89,14 +91,13 @@
 
 - `PENG`
 - `GANG`
+- `HU`
 - `PASS`
 
-`HU` 的动作入口和事件枚举虽然已预留，但真正候选生成依赖胡牌判定完成后再接入。
+其中：
 
-因此要区分两个状态：
-
-1. 接口和模型层：`HU` 已被保留
-2. 当前实际候选生成层：以 `PENG / GANG / PASS` 为主
+1. 弃牌响应窗口支持 `HU / PENG / GANG / PASS`
+2. 补杠抢杠胡窗口支持 `HU / PASS`
 
 ---
 
@@ -135,27 +136,30 @@
 - `seat 1` 和 `seat 3` 同时都能 `PENG`
 - 则 `seat 1` 获胜
 
-### 4.3 为什么不在 V1 支持一炮多响
+### 4.3 为什么在 V1 只对 `HU` 支持一炮多响
 
-这是一个项目级工程取舍，不是宣称外部规则世界只有这一种。
+这也是一个项目级工程取舍，不是宣称外部规则世界只有这一种。
 
 原因：
 
-- 一炮多响会直接放大以下复杂度：
-  - 多赢家结算
-  - 胡牌先后次序
-  - 胡后谁退出牌局、谁继续
-  - 多人同时胡后下一个行动座位怎么定
-- 当前项目还未完成：
+- `HU` 多赢家是血战到底中较常见、且用户感知较强的规则
+- 当前后端已经具备：
   - 胡牌判定
   - 基础结算
-  - 胡后继续行牌完整链路
+  - 胡后继续行牌主链
+  - 结算历史沉淀
+- 但如果把 `PENG / GANG` 也做成多赢家分支，会明显抬高后续行牌复杂度
 
-所以 `V1` 先采用：
+所以 `V1` 采用：
 
-- `单窗口单胜出动作`
+- `HU` 可多赢家同窗裁决
+- `PENG / GANG` 仍然单赢家裁决
 
-后续若要升级到一炮多响，应作为 `V2` 明确需求，不应在当前实现里偷偷混入。
+这样做的好处是：
+
+- 保住高价值规则一致性
+- 又不破坏现有统一动作入口、统一响应窗口和统一结算出口
+- 仍符合 `KISS`
 
 ---
 
@@ -190,16 +194,21 @@
 
 #### V1
 
-- 不实现完整 `过水不胡`
-- 只保证“同一响应窗口内，PASS 后不能反悔”
+- 不实现完整地方化 `过水不胡`
+- 当前只实现“最小正式版”：
+  - 玩家在响应窗口里本可 `HU` 但选择 `PASS` 时，记录一次响应禁胡状态
+  - 在该玩家下一次真正摸牌前，后续弃牌胡与抢杠胡都不再给出 `HU` 候选
+  - 下一次真正摸牌后解除限制
+  - 不影响 `PENG / GANG`
+  - 不影响自摸胡
 
 #### V2
 
 - 评估是否加入：
-  - 玩家错过可胡后，直到自己下一次摸牌或动牌前不能再胡
   - 是否仅限制同张牌
   - 是否限制同一路听牌
   - 是否允许加番后破除限制
+  - 是否需要把“解除时机”细化为摸牌、碰杠、换巡或加番后解除
 
 ---
 
@@ -323,20 +332,25 @@
 - 新动作基础校验
 - 新动作事件模型
 - 响应候选模型
+- 响应窗口停顿与关闭
+- 基于窗口的多人响应收集
+- `HU` 候选生成与胡牌判定
+- `HU` 的一炮多响裁决
+- 抢杠胡窗口
+- 最小正式版 `过水不胡`
 - 结构化私有动作消息
 - H5 原型页候选消息展示占位
 
 当前尚未完成：
 
-- 真正的响应窗口停顿
-- 基于窗口的多人响应收集
-- 优先级裁决器
-- `HU` 候选生成与胡牌判定
+- 前端正式动作面板联调
+- 更完整的地方化 `过水不胡`
+- 规则模式配置层
 
-因此本文件的直接用途是：
+因此本文件当前的直接用途是：
 
-- 让下一步裁决实现有明确规则依据
-- 降低“每轮新对话都重新讨论优先级”的沟通成本
+- 让后续前后端联调和规则扩展有明确规则依据
+- 降低“每轮新对话都重新讨论响应口径”的沟通成本
 
 ---
 
@@ -346,12 +360,12 @@
 
 1. 血战到底按成都麻将大框架实现
 2. 不可吃，只处理 `碰 / 杠 / 胡 / 过`
-3. 当前第一阶段只围绕“弃牌后响应”建窗口
+3. 当前响应窗口覆盖“弃牌后响应”与“补杠后的抢杠胡响应”
 4. 优先级固定为 `HU > GANG > PENG > PASS`
-5. 同优先级按出牌者之后最近顺位优先
+5. 同优先级按出牌者之后最近顺位优先，且 `HU` 支持一炮多响
 6. `PASS` 仅放弃当前窗口
-7. 当前不实现完整 `过水不胡`
-8. 当前不实现 `一炮多响`
+7. 当前实现最小正式版 `过水不胡`，解除时机为该玩家下一次真正摸牌
+8. 当前只对 `HU` 实现一炮多响，`PENG / GANG` 仍保持单赢家裁决
 
 如果后续要改这些口径，必须先更新本文件，再改代码。