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>

docs/admin/03-data-model.md

@@ -36,6 +36,7 @@ db, _ := sql.Open("sqlite", dsn)
 | `busy_timeout(5000)` | 拿不到锁时最多等 5 秒，而不是立刻报错 |
 | `journal_mode(WAL)` | 读和写可以同时进行，不互相锁死 |
 | `foreign_keys(1)` | 打开外键约束（SQLite 默认是**关**的） |
+| `_txlock=immediate` | 事务一开始就拿写锁，见下 |
 
 **为什么不能用 `db.Exec`：** Go 的 `database/sql` 是一个**连接池**。
 `db.Exec("PRAGMA busy_timeout=5000")` 只作用于当时拿到的那一条连接，
@@ -46,6 +47,20 @@ db, _ := sql.Open("sqlite", dsn)
 这个坑在开发时不容易发现——单线程跑一切正常，一并发就炸。
 本项目的并发领取测试就是被它绊倒过一次。
 
+**为什么必须加 `_txlock=immediate`：** Go 的 `db.Begin()` 默认发的是
+`BEGIN DEFERRED`——事务开始时**不拿写锁**，等第一次写才去拿。
+于是多个事务能同时开始、各自先读，然后同时想升级成写，互相卡死。
+这种情况 `busy_timeout` **救不了**，等下去也不会有结果。
+
+实测（6 个并发事务，每个先读后写）：
+
+| DSN | 失败数 |
+|---|---|
+| 默认 deferred | **5 / 6** |
+| 加 `_txlock=immediate` | **0 / 6** |
+
+加上之后事务一开始就排队拿锁，拿不到就按 `busy_timeout` 等，这才是要的行为。
+
 `[建议]` 同时限制连接数：
 
 ```go
@@ -322,7 +337,33 @@ CREATE INDEX idx_tasks_order  ON tasks(order_no);
 
 状态含义见 [01 需求](01-requirements.md) §6.2。
 
-## 7. `clients` 客户端
+## 7. `task_claims` 领取历史
+
+记录"哪台客户端领过哪个任务"。
+
+```sql
+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);
+```
+
+**为什么需要这张表：** [04 Client 接口实现](04-client-api.md) §4.1 要求
+"只有**从未分配给该客户端**的任务才返回 403"。
+但 `tasks.assigned_client` 只记**当前**归属，任务一旦重派给别人，
+就查不出原来那台领过了——而契约又明确要求
+"**已重派仍要接受原客户端提交的结果**"。没有这张表，那条规则根本没法判断。
+
+顺带得到一份审计记录：这个任务被哪几台客户端领过。
+
+`[必须]` 领取成功时写入；提交结果时用它做权限判断。
+同一客户端重复领同一任务只更新时间，不报错。
+
+## 8. `clients` 客户端
 
 ```sql
 CREATE TABLE clients (
@@ -344,7 +385,7 @@ CREATE TABLE clients (
 - `[必须]` 注册发生在**领取任务时**，新序列号新增、已有的更新，
   **不设单独的注册或心跳接口**，见 [04](04-client-api.md) §3。
 
-## 8. 数据关系总览
+## 9. 数据关系总览
 
 ```text
 shopee_products ──1:N──→ shopee_skus
@@ -359,7 +400,7 @@ syb_orders ────────────────────┘
       └──创建──→ tasks ──分配──→ clients
 ```
 
-## 9. 与 Client 数据模型的关系
+## 10. 与 Client 数据模型的关系
 
 Admin 和 Client **各有一个 SQLite，互不相通**，只通过接口交换数据。