docs(pm-dispatch): 「卡先于弹窗」 names chat prose that lists options as the popup

A chat message that lists options and waits for the maintainer to choose is the
same channel as the AskUserQuestion widget: the needs-user-decision card comes
first, in both shapes. Reworded in place (118 bytes, 319/319 lines unchanged);
the dropped inbox-cadence words survive at the needs-user-decision label row and
the seat-side no-waiting rule.

Claude-Session: https://claude.ai/code/session_012PxNHU3dfov2hbpg9ycZ8q
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.claude/skills/pm-dispatch/SKILL.md

@@ -265,7 +265,7 @@ PM 的工作是循环:选卡 → 认领 → 派发 → 收集 → 复核 → 报
 - 长远合理性权重恒 ≥50%:推荐以长远的读数领起,四轴冲突时其余各轴合起来投不翻它。
 - 权重只排推荐不授权:读缩小特例与契约增生,⛔ 不背书投机扩张、不放行人工地板事。
 - 四维分析从业务角度写;四棱是四轴的卡面序列化,一一对应,也是分诊代裁置信门的输入。
-- 卡先于弹窗:需裁决先落 `needs-user-decision` 卡;收件箱由维护者定期消化,⛔ 不 assign 推送。
+- 卡先于弹窗:需裁决先落 `needs-user-decision` 卡;列选项等答的聊天即弹窗;⛔ 不 assign 推送。
 - 决策卡带选项、推荐、证据、四棱块与工作量列;受阻执行卡同笔挂 `pm:blocked`+`Blocked-by:`。
 - `AskUserQuestion` 只是在场加速器:仅当维护者在本会话 ~30 分钟内有过人类输入才可发。
 - 每问必带推荐项,被 Skip 或长挂即转卡通道,⛔ 不重弹。