feat: 实现结果提交接口与幂等处理

补齐 submit_result / submit_failure，Admin 侧的三个接口全部可用，
Client 的完整一圈（领取 → 执行 → 提交）现在能走通了。

实现
- 幂等：idempotency_keys 表。同键同内容返回上次的响应且不重复落库，
  同键不同内容返回 409。幂等记录与业务写入在**同一事务**，
  分开写的话业务成功但幂等没记上，重试会被重复处理
- 无条件接受（契约 §4.1，最容易写错的一条）：
  任务已取消、已重派给别人，都照样接受结果——客户端中途不查任务状态，
  必然会提交"Admin 这边已经不要了"的结果，而它可能真的已经下过单，
  这些数据必须留痕
- 采集任务的结果落到商品级 shopee_products.pdd_data 并置 collected；
  失败则置 failed 并把原因写进 collect_error，操作员才看得见
- 失败状态映射：retry_wait→assigned，其余同名
- 三个接口都刷新 last_seen_at

新增 task_claims 表（migrations v2）
契约要求"只有从未分配给该客户端的任务才返回 403"，但 assigned_client
只记当前归属，重派后就查不出原来那台领过——而契约又要求那种情况必须接受。
没有这张表这条规则根本没法判断。顺带得到一份审计记录。

修复第二个并发 bug：事务必须 BEGIN IMMEDIATE
并发提交报 SQLITE_BUSY。根因是 Go 的 db.Begin() 默认发 BEGIN DEFERRED，
事务开始时不拿写锁，多个事务各自先读再想升级成写就互相卡死，
这种情况 busy_timeout 救不了。DSN 加 _txlock=immediate 后事务一开始
就排队拿锁。实测 6 个并发事务：默认失败 5/6，加参数后 0/6。
已写进 docs/admin/03-data-model.md §2.1。

已验证（Go 1.23.0）
- 30 个单元测试全过，并发用例重复 20 次稳定通过
- 端到端：claim 200 → 提交 200 → 重复提交返回完全相同的响应 →
  同键不同内容 409 → 没领过的客户端 403 → 任务不存在 404 →
  缺 Idempotency-Key 400；库里 task=succeeded、幂等 1 条、领取历史 1 条

说明：Gitea 尚未配置，本次无对应工单号。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

admin/repository/db.go

@@ -20,6 +20,17 @@ import (
 	_ "modernc.org/sqlite"
 )
 
+// Execer 让同一个 repository 函数既能直接用 *sql.DB，
+// 也能在事务里用 *sql.Tx。
+//
+// 需要"多张表要么一起改、要么都不改"时，service 开一个事务，
+// 把 *sql.Tx 传进来即可，不用为事务再写一套函数。
+type Execer interface {
+	Exec(query string, args ...any) (sql.Result, error)
+	Query(query string, args ...any) (*sql.Rows, error)
+	QueryRow(query string, args ...any) *sql.Row
+}
+
 // Open 打开 data/admin.db。
 //
 // **PRAGMA 必须写在 DSN 里，不能用 db.Exec("PRAGMA ...") 设置。**
@@ -37,10 +48,13 @@ func Open(dataDir string) (*sql.DB, error) {
 	//   busy_timeout  拿不到锁时最多等 5 秒，而不是立刻报错
 	//   journal_mode  WAL 模式，读和写可以同时进行
 	//   foreign_keys  打开外键约束（SQLite 默认是关的）
+	//
+	// _txlock=immediate 是另一个**必须加**的参数，原因见下。
 	dsn := "file:" + path +
 		"?_pragma=busy_timeout(5000)" +
 		"&_pragma=journal_mode(WAL)" +
-		"&_pragma=foreign_keys(1)"
+		"&_pragma=foreign_keys(1)" +
+		"&_txlock=immediate"
 
 	db, err := sql.Open("sqlite", dsn)
 	if err != nil {
@@ -55,6 +69,21 @@ func Open(dataDir string) (*sql.DB, error) {
 	db.SetMaxOpenConns(4)
 	db.SetMaxIdleConns(4)
 
+	// 关于 _txlock=immediate：
+	//
+	// Go 的 db.Begin() 默认发的是 BEGIN DEFERRED——事务开始时**不拿写锁**，
+	// 等到第一次写才去拿。于是多个事务可以同时开始、各自先读，
+	// 然后同时想升级成写，互相卡死，直接报 SQLITE_BUSY。
+	// 这种情况 busy_timeout **救不了**：等下去也不可能有结果，
+	// 只能让某个事务整个重来。
+	//
+	// 加上 _txlock=immediate 后，事务一开始就拿写锁，
+	// 拿不到就按 busy_timeout 排队等——这才是我们要的行为。
+	//
+	// 实测（6 个并发事务，每个先读后写）：
+	//   默认 deferred     失败 5/6
+	//   _txlock=immediate 失败 0/6
+
 	// sql.Open 是懒加载的，这里主动连一次，好让配置错误立刻暴露
 	if err := db.Ping(); err != nil {
 		db.Close()
@@ -192,6 +221,25 @@ var migrations = [][]string{
 	    created_at    TEXT NOT NULL
 	);`,
 	},
+
+	// v2: 领取历史。
+	//
+	// 为什么需要它：契约要求"只有**从未分配给该客户端**的任务才返回 403"
+	// （docs/admin/04-client-api.md §4.1）。但 tasks.assigned_client 只记
+	// **当前**归属，任务一旦重派给别人，就查不出原来那台领过——
+	// 而契约又明确要求"已重派仍要接受原客户端提交的结果"。
+	// 没有这张表，那条规则根本没法判断。
+	//
+	// 顺带得到一份审计记录：这个任务被哪几台客户端领过。
+	{
+		`CREATE TABLE task_claims (
+	    task_id     TEXT NOT NULL,
+	    client_id   TEXT NOT NULL,
+	    claimed_at  TEXT NOT NULL,
+	    PRIMARY KEY (task_id, client_id)
+	);`,
+		`CREATE INDEX idx_task_claims_client ON task_claims(client_id);`,
+	},
 }
 
 // Migrate 把数据库升到最新版本。