fix(ac15): 种子写入失败时给可自解释的文案（不改断言）

按 team-lead 裁决：**不加"该表无 FK"的前置断言，改报错文案**。理由（我认同）：
① "表上没有 FK"是 schema 现状，不该由一条 case 的前置断言来守 —— 那等于把 case 变成
   schema 的看门神，将来正经加 FK 时会以"某条 case 失败"的形式挡在**错误的位置**；
② 真加了 FK，红在种子阶段**恰恰是正确信号**（那时种子确实写不进去），
   问题不在"红了"，在"红得让人误判"；
③ 所以修法是**让文案自己解释**，断言只能拦住，拦不住人的判断。

新文案三句：写失败的是哪一列 / 该列**故意不种** `t_courses_student` 且依赖"该表无 FK" /
⇒ 若你刚加了外键这是预期行为（需同时补种子），否则是种子写错。

验收：47 条 47 PASS / 0 FAIL / Skipped 87 / 未分类 0（判据未动）。

internal/academic/dualrun/stage2/c1_activity.go

@@ -455,7 +455,12 @@ INSERT INTO t_courses_activity_user_discount_log
   (activity_user_discount_id, courses_student_id, discount_amount_used, create_time, memo)
 VALUES (?, ?, ?, NOW(3), ?)`,
 			poolID, c.StuCourseNumericID, yuan(dl.MoneyCents), dl.Memo).Error; err != nil {
-			return fmt.Errorf("种子 target 额度流水失败：%w", err)
+			// 这条报错文案要把"预期内"和"真错"分开 —— 断言只能拦住，拦不住人的判断。
+			return fmt.Errorf("种子写入 t_courses_activity_user_discount_log.courses_student_id=%d 失败：%w\n"+
+				"  该列**故意不种** `t_courses_student`（本 case 不校验报课行存在性；"+
+				"比对里 `#<numeric>` 兜底归一依赖「该表无 FK」）。\n"+
+				"  ⇒ 若你**刚给这张表加了外键**，这是预期行为，需要同时给 case 补 `t_courses_student` 种子；"+
+				"否则请检查是不是种子本身写错了。", c.StuCourseNumericID, err)
 		}
 	}
 	// 用量流水：`order_no` 与 legacy 的 `orderid` 同一个字符串（两侧游标靠它定位）。