修复(#132): 退款幂等校验 + 已退款订单防重新激活

P01：refundOrderLogic.RefundOrder 在事务内 FOR UPDATE 后、lockCommissionSource 前新增
333 退款日志扫描，命中即返回 OrderAlreadyRefunded(61006)，不再写日志/扣 commission/
改 order.status。

P02：堵住已退款订单状态被回退入口
- queue/logic/order/stuckOrderRecoveryLogic.go：批扫 status=6 时新增 333 日志守卫，
  已退款订单不再被重置为 5 + 重新入队 activate（HIF-131 trace 中订单 53647 被刷回 5
  的真凶）
- queue/logic/order/activateOrderLogic.go：releaseClaim 同步加守卫做防御性兜底

新增 internal/model/log/refund.go 共享 helper HasRefundCommissionLog：
type=33 + content LIKE 走索引粗筛，再 JSON 反序列化确认 content.type==333 AND
content.order_no==orderNo，防 LIKE 子串误判。

测试：单元测试覆盖正常退款 / 已有 333 日志拒绝 / 子串误判防御 / 脏 JSON 容错；
sqlmock 严格断言命中后事务序列只含 BEGIN/SELECT order FOR UPDATE/SELECT
system_logs/ROLLBACK，无任何 commission 写入。

不做：calculateCommission、status 枚举拆分、表结构变更、支付通道 notify、用户余额回补。

Co-authored-by: multica-agent <github@multica.ai>

internal/model/log/refund.go

@@ -0,0 +1,38 @@
+package log
+
+import (
+	"fmt"
+
+	"gorm.io/gorm"
+)
+
+// HasRefundCommissionLog 判断指定订单号是否已写入 333 退款佣金日志。
+// 用于 refund 主流程做幂等校验，以及 stuck-order recovery / activate worker
+// 区分「已退款」（terminal）与「短暂 claimed」（transient）这两种共用 status=6
+// 的语义。
+//
+// 实现细节：
+//  1. type=33 + content LIKE '%"order_no":"<orderNo>"%' 先走索引粗筛；
+//  2. 命中项再用 JSON 反序列化精确比对 content.type==333 与 content.order_no，
+//     避免 order_no 出现在其它字段子串里产生误判。
+func HasRefundCommissionLog(tx *gorm.DB, orderNo string) (bool, error) {
+	if orderNo == "" {
+		return false, nil
+	}
+	var logs []SystemLog
+	if err := tx.Model(&SystemLog{}).
+		Where("type = ? AND content LIKE ?", TypeCommission.Uint8(), fmt.Sprintf("%%\"order_no\":\"%s\"%%", orderNo)).
+		Find(&logs).Error; err != nil {
+		return false, fmt.Errorf("query refund commission log failed: %w", err)
+	}
+	for _, item := range logs {
+		var content Commission
+		if err := content.Unmarshal([]byte(item.Content)); err != nil {
+			continue
+		}
+		if content.Type == CommissionTypeRefund && content.OrderNo == orderNo {
+			return true, nil
+		}
+	}
+	return false, nil
+}