支付按「支付尝试」收敛，不再「不确定即停摆」

一笔待支付订单的支付结果问不出来时，旧规则把整笔订单停摆：不许再付、也不许取消。这既堵死了用户
（放弃微信收银台是未支付订单最常见的路径），也让「关单」这个唯一能作废预支付单的手段永远不被调用——
因为关单被排在查单之后，而查单答「处理中」就直接返回。改为**按支付尝试收敛**：一笔订单同一时刻最多
只有一张活着的**预支付单**，重付优先复用本地已存的支付参数，其次关单作废，都走不通才新建；取消以查单
确认「钱没有收下」为准（2026-09-17 修订，原为「以关单回执为准」）；「支付结果不确定」只约束它所属的
那一次尝试，不约束整笔订单。订单到期先关单再取消，
到期后不允许补付；带未定局尝试的订单不自动取消；通道确认收到、但订单已取消的钱自动退回付款人。

这条不是新决定，是补 2026-09-10 审计 §8 的后半段。那份报告给的修复方向是「**关单中状态**、通道关单与
主动查单、成功事实落账、取消后成功的退款补偿、差错告警**必须共同存在**」——前四项里前两项与后两项
已经落地，缺的正是「关单中状态」与「取消后成功的退款补偿」这两项。术语见 CONTEXT.md
「支付尝试与预支付单」一节。

考虑过但没选的

• 维持「不确定即停摆」，只加一个超时兜底。 超时之后没有好选择：直接取消可能把已收下的钱变成悬账，
  继续等待则用户面对的仍是一个既不能付也不能取消的页面，只是等得更久。
• 每次重付都新开一张预支付单。 实现最省事，但同一笔订单会有两张可被支付的预支付单；审计 §9 已经
  复现过「一个订单、两个请求键、两次预授权」，而通道确认两笔都成功时没有多收款退回流程。
• 把"关单中"做成用户可见的失败态。 关单回执说「处理中」时，通道其实还可能在收钱，所以不能当成功，
  但它也不该是终点。做成可等待、可重试的中间态，才能既不假装关掉、又不把用户堵死。
• 关单中期间允许直接落成已取消。 只有在取消后收到钱能自动退回付款人的前提下才成立（本 ADR 已包含
  自动退款），否则就是把悬账留给人工。**2026-09-17 修订后改成选它，见文末。**

2026-09-17 修订：取消不等关单结论

真机复测暴露：用户点「取消订单」之后要等关单结论才落地，而通道对刚创建的微信交易**最常见的答复就是
「关单处理中」**（实测三次取消全部如此），叠上对账扫描周期，用户看到的就是「点了取消一直卡着」。可他
根本没付过钱——这笔钱本来就没动，没有任何理由让他等。按上面「关单中期间允许直接落成已取消」那条的前提
（取消后收到钱能自动退回付款人），在本 ADR 的悬账自动退款落地之后已经成立，于是改为：

取消在查单确认「钱没有收下」之后就生效，不再等关单回执。

• 查单明确说钱已收下：不取消，落成已支付并告知用户。这条不变，它是「不谎报钱」的底线。
• 查单说没收款、或者问不通（通道不可达）：按用户意图**立刻**取消订单。
• 关单照做，但只是尽力而为：它的结论只决定这次尝试的本地终态——关掉了就落成 CLOSED（不必再盯），
  没关掉就留成 CLOSING／CANCEL_UNCONFIRMED，由对账盯着并继续关。
• 关单回执说「原交易可能已成功」而查单又查不到时，同样立刻取消；那条 PAYMENT_CLOSE_CONFLICT 问题记录
  继续留给人工，钱真进来了走悬账退款，人才端订单显示「已退款」。

代价记在这里：偶发「用户付了钱又被自动退回」。它要求用户在点取消的同一刻正在完成支付——通常是
他自己在支付途中返回、又去点了取消——并且正好落在「查单之后、凭证被关掉之前」那几秒里。多走的是一笔
真实的收款+退款流水（手续费大概率不退，对账也要处理），换来的是取消立刻生效。这是产品明确选的取舍：
取消是高频操作，「等一分钟」是每次都要付的代价；「收了再退」是极少数情况。

同时把取消意图降级为审计事实：benefit_order.cancel_requested_at（V154）只记录用户何时点的取消，
不再驱动任何行为——它驱动的那个「等关单结论再落地」的对账扫描已经删掉，留它只是为了在
「取消后收到钱」那类偶发路径上把时间对得上。