审计修复：后端（安全 / 数据一致性 / 性能）

audit-2026-09-21.md 里的后端条目落地。每条都配了回归守卫，并逐条做过变异验证
（注入原 bug → 确认按正确理由变红 → 还原 → 变绿）。

安全
- CSRF 只加同源 Origin/Referer 守卫（csrf.go），不动模板
- 会话 cookie 的 Secure 按请求判断；两步验证两闸（loginGuard + 验证码一次性）
- 跳转收口到 safeInternalPath；clientIP 只认 XFF 最后一段
- GPX 按属主圈定且查 RowsAffected；下载名走 downloadDisposition
- 上传口统一 MaxBytesReader；落盘后的失败路径清掉半成品

数据一致性
- 区域判定两端各过一遍再 AND（apiTrack 与 movementsWhere 对齐）
- Filter.Verdict 全域一致（下推到 visitsWhere）；聚合刷新必须返回 error
- 附属数据改挂坐标键，Go 与 SQL 两套表达式逐位一致
- 脏备份的伪时间/越界坐标不再进领域模型；rows 循环统一 drainRows
- 合并与导出：writeRawRow 上抛错误、悬空引用清理、原生列补全

性能
- placeCols 相关子查询带 dataset_id 前导列；findSourceArchive 先按大小筛
- 批量勾选改 ANY($3::bigint[])；fillupCache 加上限；同一查询不再查两遍

另：新增「全新库」冒烟测试 —— 空库跑完 Migrate 再用应用侧读查询真打一遍，
迁移块排到依赖表之前这种错只有新库会炸，老库毫无症状。

internal/web/backup_merge.go

@@ -731,8 +731,10 @@ func writeRawRow(ctx context.Context, ex execer, dsID int64, entity string, pk i
 	}
 	blob, err := json.Marshal(raw)
 	if err != nil {
-		log.Printf("留档 %s#%d 序列化失败: %v", entity, pk, err)
-		return nil
+		// 这里以前只 log 后 return nil：调用方会以为留档成功，合并照常提交，
+		// 于是这行的原始列永久缺失（下次比对认不出 UUID、导出也还原不回去）。
+		// 必须上抛，让整个合并事务回滚。
+		return fmt.Errorf("留档 %s#%d 序列化失败: %w", entity, pk, err)
 	}
 	_, err = ex.ExecContext(ctx, `INSERT INTO entity_raw (dataset_id, entity, src_pk, raw, skipped)
 		VALUES ($1,$2,$3,$4,false)