fix(payment): 渠道已收款时不再把支付单回滚成支付中

租客在待支付超时或取消的最后几十秒完成付款时，订单先被取消，乐刷的支付
结果几秒后才到，入账被判定订单不可支付而拒收。原先订单推进和支付单更新
在同一个事务里，订单一报错整笔回滚，支付单停在支付中且 paid_at 为空：
钱已在渠道，系统却毫不知情。乐刷重试十次后放弃，之后既补不回入账（订单
不再是待支付），后台人工退款也发不出去（退款要求原支付单是已支付）。
日志保留期内 13 天出了 5 笔，合计 4085.60 元。

- 取消前核对渠道：超时取消、租客取消、客服关单都先查一次渠道，已收款并
  已推进订单就放弃取消，让支付正常入账而不是走退款。渠道异常时按未收款
  继续，避免渠道一抖订单全卡住
- 回调兜底记账：订单确实已结束时不再回滚，把支付单如实记成已支付并写入
  paid_at 与渠道单号，后台人工退款从此可用。退款仍由客服人工发起
- 客服关单：待支付订单按实际已收款减已退款的差额退，补上本次事故中关单
  不生成退款的直接原因
- 补齐日志上下文：回调入账失败原先只有 error="order cannot pay"，现在带
  支付单号、订单号、订单状态和金额；新增 ERROR「渠道已收款但订单无法入账，
  需人工退款」作为唯一需人工介入的告警

Co-authored-by: Cursor <cursoragent@cursor.com>

backend/internal/modules/payment/notify.go

@@ -50,7 +50,19 @@ func (r *Repository) HandleNotify(ctx context.Context, provider string, params m
 		return nil, ErrPaymentVerifyFailed
 	}
 	raw := withNotifyDiagnostic(params, rawPayload, contentType, verify, "verified")
-	if err := r.applyChannelStatus(ctx, payment, normalizeNotifyPaymentStatus(runtimeConfig.Provider, params["status"]), params["pay_time"], raw, channelSourceNotify); err != nil {
+	channelStatus := normalizeNotifyPaymentStatus(runtimeConfig.Provider, params["status"])
+	if err := r.applyChannelStatus(ctx, payment, channelStatus, params["pay_time"], raw, channelSourceNotify); err != nil {
+		// 入口处的 WARN 只有渠道参数，定位不到是哪个订单哪笔支付单，这里补齐上下文。
+		r.log().Warn("支付回调入账失败", paymentLogFields(ctx, appendFields(
+			paymentOrderFields(payment),
+			runtimeConfigFields(runtimeConfig),
+			[]zap.Field{
+				zap.String("channel_status", channelStatus),
+				zap.String("order_status", r.orderStatus(ctx, payment.OrderID)),
+				zap.Error(err),
+			},
+		)...,
+		)...)
 		return nil, err
 	}
 	return &NotifyResult{OK: true, Message: "000000"}, nil