图片恢复支持对象存储（R2）；专题也改成归人不归数据集

R2 上的图怎么救：库里的行没了就只剩桶里有那些键，不列桶无从得知它们叫什么。
给 internal/media 加了 ListObjects（ListObjectsV2 + SigV4 + 自动翻页 + XML 解析）：
- 路径式访问、请求只到桶；查询串必须**先百分号编码再签名**（canonicalQuery 按原样取
  RawQuery，两边得是同一份字节，prefix 里的 / 要写成 %2F）。
- ⚠️ R2 的 API Token 默认只给对象读写，没有 s3:ListBucket 就 403。列桶失败**不让整个
  恢复失败**：本地那半照救，原因进 Warnings、页面用红色提示条显示（否则站长会以为恢复完了）。
- 候选对象 = 本地目录 ∪ 桶里 .webp（同键以本地为准）；行的 storage 按「对象实际在哪」写，
  bytes 用桶里报的 Size。另加一条 warning：挂回了却没配 s3_public_base ⇒ 行有了页面空白，
  这比「没恢复」更难懂。

专题（用户拍板「一并做」）：topics.dataset_id 同样带 CASCADE，删数据集带走专题，而专题
只存在这张表里、没有恢复来源。外键摘掉，所有查询 dataset_id → user_id（loadTopics、
topicPage、保存/删除/开关、pageBase.HasTopics）；**内容仍照当前生效数据集算**
（topicContent 不动）——变的是「这份定义归谁」。Dataset 补 UserID 供前台按属主定位
用户级数据；管理专题不再要求有生效数据集。

导出链路未改动：place_images / topics / Dataset.UserID 都不参与 .rondbackup 导出，
全量验收（含导出保真、ZRAW 夹取、编号对齐那批）PASS=331 FAIL=0 SKIP=0。

.workbuddy/memory/2026-09-30.md

@@ -241,3 +241,21 @@ UUID 集合也与换之前逐条一致）。
 并给夹具补了收尾清理（外键没了，必须自己清）。
 
 新增用例 4 条（`image_recovery_test.go`）。
+
+### 补记（23:20）：对象存储上的图 + 专题一并改
+
+用户：「一并做，而且有部分资源在 R2 上，怎么办？」
+
+**R2 侧**：行没了就只剩桶里有那些键，不列桶无从得知它们叫什么 ⇒ 给 `internal/media` 加了
+`ListObjects`（ListObjectsV2 + SigV4 + 翻页 + XML）。两个坑：查询串必须**先编码再签**
+（`canonicalQuery` 按原样取 RawQuery，prefix 里的 `/` 得写成 `%2F`，否则签名与发送不是同一份字节）；
+R2 的 Token 默认没有 `s3:ListBucket` ⇒ 403。列不动时**不让整个恢复失败**：本地那半照救，
+原因进 `Warnings`（页面红色提示条）。另外「挂回了却没配 `s3_public_base`」会让行有了、页面一片空白，
+比「没恢复」更难懂，也写进 warning。
+
+**专题**：按用户拍板做成归人不归数据集。外键摘掉，所有查询 `dataset_id` → `user_id`
+（`loadTopics`/`topicPage`/保存/删除/开关/`HasTopics`）；**内容仍照生效数据集算**（`topicContent` 不动）。
+`Dataset` 补 `UserID`（`datasetFor` 多查一列）供前台按属主定位用户级数据。
+用例除「删数据集后专题还在」外，还直接查 `pg_constraint` 确认外键确实不在——只看行为可能被别的原因弄绿。
+
+**导出链路没碰**：`place_images` / `topics` / `Dataset.UserID` 都不参与 `.rondbackup` 导出。