图片不再随数据集删除：加「图片挂载恢复」，place_images 摘掉外键

用户报「之前上传的照片找不到了，应该是因为清了应用数据换基线」。查下来与 App 侧无关，
是站点自己两套口径打架：

- place_images.dataset_id 带 ON DELETE CASCADE，而读取按 place_key 坐标键、跨数据集。
- 于是删掉旧数据集时图片**行**被级联删了，**文件却留在 media 目录里**。
- 实测（本机）：datasets 只剩 155 号、place_images 0 行、盘上 4 个 .webp 好端端躺着。
  同一批附属数据里备注（17）与结论（3+1）因为早就迁到坐标键，毫发无损——只有图片倒霉。

三件事：

1) 恢复：后台首页「图片挂载恢复 → 扫描并恢复」（POST /admin/images/recover，
   internal/web/image_recovery.go）。只插行、不删文件、不看数据集，按 object_key 判重可反复点。
   认地点两处来源：数据集还在就查它的 places；数据集已删就读它留下的 baselines/<id>.sqlite
   还原「地点号 → 坐标」。对象键两种历史布局都认（<ds>/<YYYYMM>/<srcPK>-<hash>.webp 与
   <ds>/<srcPK>/<hash>.webp）；判据先看文件名有没有 `<数字>-` 前缀，再看中间目录——
   地点号也可能刚好 6 位，只看位数会认错。

2) 防复发：CREATE TABLE place_images 去掉外键 + 幂等 DROP CONSTRAINT；删图接口不再按
   dataset_id 过滤（数据集删了也得能删图）；「删除数据集」的二次确认文案改成实话。

3) 报告同类陷阱（未改）：topics 仍带 CASCADE，专题随数据集一起删且没有恢复来源。

测试踩到的坑：图片「按坐标键跨数据集读」+「按 object_key 判重」都不看数据集，用例之间会
互相污染两处——盘上文件（报「应当 2 张、实际 10 张」）与库里的行（Already:1 让兜底分支
根本没跑到，用例差点假绿）。加 isolateImageState（换空 DataDir + 按 place_key 清历史行），
并给夹具补收尾清理（外键没了必须自己清）。

新增用例 4 条；验收：./scripts/verify.sh 全量 PASS=323 FAIL=0 SKIP=0。

internal/web/movement_e2e_test.go

@@ -11,6 +11,7 @@ import (
 	"net/url"
 	"os"
 	"path/filepath"
+	"strconv"
 	"strings"
 	"testing"
 	"time"
@@ -119,6 +120,14 @@ func newMovementFixture(t *testing.T) *movementFixture {
 	if err != nil {
 		t.Fatalf("初始化服务失败: %v", err)
 	}
+	// 图片的清理要自己来：place_images 只认坐标键、**不再随数据集级联**（见 schema 里的说明），
+	// 所以删用户/删数据集都不会带走它。不显式清的话，上一个用例留下的行会在按坐标键读图时
+	// 被算进下一个用例（实测「应当 2 张、实际 4 张」就是这么来的）。
+	// 注册得最晚 ⇒ t.Cleanup 后进先出，它会在删用户之前跑。
+	t.Cleanup(func() {
+		pg.ExecContext(ctx, `DELETE FROM place_images WHERE dataset_id=$1`, dsID)
+		os.RemoveAll(filepath.Join(cfg.MediaDir(), strconv.FormatInt(dsID, 10)))
+	})
 	return &movementFixture{cfg: cfg, pg: pg, srv: srv, dsID: dsID, src: src,
 		ctx: ctxWithUser(&auth.User{ID: uid, Username: user})}
 }