fix(payment): 取消意图落库自动落地，对账间隔回到设计的一分钟

第一轮修复在真机上已生效（订单 539 的第一张死凭证落成 CLOSED 后，再点支付新建了 attempt 2 并付成功），
但真机复测仍报「点了取消还是卡住」。只读核对开发库后找到本票没兑现的两处：

- 关单补偿实际是五分钟一轮：CLOSE_RETRY_MINUTES=1 只是「距上次处理满一分钟」的资格窗口，扫描本身由
  fixed-delay-ms 决定，默认 300000。于是「关单每分钟重试一次、最多三次」实为「每五分钟一次、最多
  十五分钟」——订单 540 在 17:15:21 拿到「关单处理中」后，用户等的那一分钟里没有任何重试发生。
  间隔默认值改为 60000，注解与 yml 两处同步；慢车道每行仍有 pending-after-minutes 与
  last_reconciled_at 双重退避，同一行不会因扫描变密而被重复查询。
- 取消意图没有落库：cancel 在关单没结论时只回 cancellationPending，订单不动；而关单后来真的关掉时
  没有任何人去取消那笔订单（giveUpClosing 只在重试到上限时跑）。用户点的取消随页面关闭而丢失，订单
  仍挂在待支付，只能再点一次取消或等 15 分钟超时。新增 benefit_order.cancel_requested_at（V151）
  记录受理时间，对账每轮在查单/关单之后执行 cancelOrdersAwaitingCloseConclusion()——每笔尝试都有
  结论且没有 SUCCEEDED 支付时，替用户把订单收成已取消。

开发库已用 scripts/apply-sql-file.ps1 落列（等价 DDL 见 scripts/dev-schema-v151-order-cancel-request.sql），
测试库由 Flyway 落列。回归三条：取消受理即落库且未定局时不取消、关单有结论后自动落地、
已收款订单绝不被取消意图取消。PaymentSchedulingConfigurationTests 改为断言「注解与配置的默认值一致」
并额外钉住那 1 分钟约束。全量 369 项，仅 testing.md 记录的 3 项基线失败。