feat: 备份恢复 / 图片清理 / 单位恢复 / 审计过滤 / 模板引擎 M1 + 两个导入缺陷修复

用户点名的三件事（模板功能、删死代码、剩余缺口）这一批全部落地，另修掉两个刚暴露的导入缺陷：

**新增能力**
- 备份恢复：`POST /api/backup/restore`（admin）。先把校验做在拍快照之前（只读打开 + integrity_check +
  关键表校验 + 异类库标志表互斥），再用 VACUUM INTO 拍「恢复前安全副本」，然后关连接、整文件替换、
  触发优雅重启；`-wal` 还在时直接拒绝（宁可失败也不让旧库 WAL 套到新库上）；恢复后审计直写"恢复之后
  还在的那份库"（不走通用 Auditor，否则记录只会落在被替换掉的旧文件上）。顺带修掉：裸服务端连续恢复
  第二次会在拍副本处崩出一句看不懂的 500，现在回 503「上次恢复后尚未重启，请先重启服务端」。
- 安全副本保留策略：每类库保留最近 5 份，独立于 .db 的 20 份滚动清理。
- 图片管理：`DELETE /api/uploads/{name}`（被引用 409 并列出引用点）、`GET /api/uploads/orphans`、
  `POST /api/uploads/orphans/delete`（只删列出的孤儿，宁漏勿误），全部 admin（与字体删除同档）；
  `deploy/backup.bat` 补上 uploads/ 归档（logs 不归档：可再生的诊断且会无上限增长）。
- 已彻底删除单位的恢复：`POST /api/teams/{id}/restore`（与 hideTeam 同档）。幂等；恢复不会把「停用」
  变成「启用」；真机确认恢复前后榜单逐字节一致、change_log 最大值不变（数据一行没动，不需要重算）。
  界面加「显示已彻底删除的单位」（仅 admin）与恢复按钮；非 admin 的删除确认框里写明"本账号无法自行恢复"。
- 审计日志按 `action` 过滤（子串模糊，输入里的 %/_/\ 转义成字面量）。
- 删除死表 recent_projects（新增 system 迁移 0006，未动已应用的迁移）。
- points_override 不再"设了没效果"：写入侧 400 + 引擎侧守卫，提示改用「积分调整」。
- 联队份额空壳清理（UnionAttribution/UnionSplit/Entry.TeamShares/resolvedShares 等；TeamShare 类型保留，
  因为 export/realtime/奖牌流水三处在生产路径上构造它）。
- 自定义大屏模板 M1：插值引擎（parseTemplate/renderTemplate），任何情况都不抛异常、未定义→空串+警告、
  警告按 (code,path) 合并计数、无 eval/innerHTML，57 个新用例。

**两个真缺陷（前两个已随 0.1.6 出包）**
- 基础数据包导入「排序」列口径不一致：小项/组别留空保持原值，单位/大项留空被写成 0（plan 没从库里
  现值起手）→ 四张表统一为「留空保持原值」。
- 同类第二处：布尔列「整列被删掉」被当成"取默认值"，会把库里所有停用的单位/大项静默改回启用 →
  改为「缺列 = 不动」（写侧与解析侧都收口，补了"缺列保持/空格子=是/显式否=停用"三组对照用例）。

**删死代码**
- createEntry / updateEntry / deleteEntry / entryEventID / checkCategoryInEvent / getEntry /
  normalizeEntryStatus / ExportBaseDataXLSX（全仓 grep 零引用）。⚠️ 随之记入文档：「组别必须属于该小项」
  这道校验现在只由导入路径"按小项+组别名解析"天然保证，将来若新增从请求体接收 categoryId 的接口，
  必须自己补校验（库层没有复合外键）。

**文档**
- devdocs 全面同步（01/02/03/04/05/06/07/09/11/12/13/README；含身份口径、延迟结算、大屏单栏新版式、
  新增路由与设置键、R18/R19 风险）；docs 复核 + 第二轮（身份口径三个易写反的分支、图片删除、备份覆盖、
  审计过滤、单位恢复、去掉硬编码版本号、上线检查清单 +5 项）；debug/使用说明 6 份逐份 diff 一致。

测试：服务端 13 包（连跑两遍）、前端 406 例、Console 28 例 + 18 文件语法检查 —— 全绿。
版本号 dev_0.1.6 → dev_0.1.7。

server/internal/domain/scoring.go

@@ -11,9 +11,6 @@ const rankEpsilon = 1e-9
 
 // ScoreOptions 控制引擎的可选行为；零值即本次运动会的口径。
 type ScoreOptions struct {
-	// UnionAttribution 决定联队成绩的归属；空值等同 UnionWhole（整体记给主单位）。
-	// 未实现：生产链路没有赋值入口，联队份额也无处加载（见 UnionAttribution 注释）。
-	UnionAttribution UnionAttribution
 	// IncludeDrafts 为 true 时草稿成绩也参与计分；默认只算已发布（草稿不上屏也不计分）。
 	IncludeDrafts bool
 }
@@ -38,7 +35,9 @@ type EventScore struct {
 }
 
 // RankedResult 记录「某条报名项在某通道下拿到的名次与原始积分」。
-// Points 尚未按联队份额拆分、也未乘个人→单位系数，因此可直接用于奖牌判定与分项成绩表。
+// Points 尚未乘个人→单位系数，因此可直接用于奖牌判定与分项成绩表。
+// Shares 是该名次的归属单位；当前只有「整体归主单位」一种口径（联队未实现），
+// 保留份额结构是因为导出 / 实时快照等消费方按份额遍历。
 type RankedResult struct {
 	EntryID     int64
 	ResultID    int64
@@ -61,6 +60,13 @@ type RankedResult struct {
 // 计分与排名解耦：项目 scored=false 或没有通道时照样产出名次（Points=0），只是不写流水。
 // 没有通道时按小项自身的录入方式（result_mode）推导排名口径，见 rankOnlyChannel。
 func ScoreEvent(in EventScoreInput) (EventScore, error) {
+	// 引擎不读取 pointsOverride，静默忽略等于「设置成功但毫无效果」；
+	// 显式报错把问题暴露在计分环节，写入侧另有 400 拦截，两道都不放行。
+	for _, r := range in.Results {
+		if r.PointsOverride != nil {
+			return EventScore{}, fmt.Errorf("%w: 成绩 %d（报名项 %d）", ErrPointsOverrideUnsupported, r.ID, r.EntryID)
+		}
+	}
 	var out EventScore
 	rankOnly := len(in.Channels) == 0
 	// 只排名不计分：scored=false 或没有计分通道时都不产出任何流水（含破纪录加分）。
@@ -355,7 +361,7 @@ func rankedResult(in EventScoreInput, ch ScoreChannel, c candidate, rank int, po
 		AthleteID:   c.entry.AthleteID,
 		AthleteName: c.entry.AthleteName,
 		TeamID:      c.entry.primaryTeamID(),
-		Shares:      c.entry.resolvedShares(in.Options.UnionAttribution),
+		Shares:      wholeShare(c.entry.primaryTeamID()),
 		Rank:        rank,
 		Points:      points,
 		Status:      c.result.Status,
@@ -462,11 +468,11 @@ func scoreByAggregate(in EventScoreInput, ch ScoreChannel, profile ScoringProfil
 			}
 			if ch.Scope == ScopeTeam {
 				rr.TeamID = c.subject
-				rr.Shares = []TeamShare{{TeamID: c.subject, Weight: 1}}
+				rr.Shares = wholeShare(c.subject)
 			} else {
 				rr.AthleteID = c.subject
 				rr.AthleteName = c.entry.AthleteName
-				rr.Shares = c.entry.resolvedShares(in.Options.UnionAttribution)
+				rr.Shares = wholeShare(c.entry.primaryTeamID())
 			}
 			v := c.value
 			rr.ResultValue = &v
@@ -507,8 +513,8 @@ func validResultValue(r Result, found bool, opts ScoreOptions) (float64, bool) {
 	return *r.ResultValue, true
 }
 
-// ledgerFromRanked 把名次明细转成积分流水：按通道 scope 决定记给个人还是单位，
-// 联队按份额拆分；0 分不产生流水，避免流水表被零分噪声撑大。
+// ledgerFromRanked 把名次明细转成积分流水：按通道 scope 决定记给个人还是单位；
+// 0 分不产生流水，避免流水表被零分噪声撑大。
 // 流水是否计入单位总分由通道的 countToTeam 决定（个人通道可以只记个人）。
 func ledgerFromRanked(in EventScoreInput, ch ScoreChannel, ranked []RankedResult) []LedgerEntry {
 	var out []LedgerEntry
@@ -550,34 +556,10 @@ func ledgerFromRanked(in EventScoreInput, ch ScoreChannel, ranked []RankedResult
 	return out
 }
 
-// resolvedShares 解析报名项的归属：默认整体归主单位，联队模式才按份额拆分。
-func (e Entry) resolvedShares(mode UnionAttribution) []TeamShare {
-	shares := e.teamShares()
-	if len(shares) == 0 {
+// wholeShare 构造「主单位独占 100%」的归属份额。联队拆分未实现，这里只产出这一种口径。
+func wholeShare(teamID int64) []TeamShare {
+	if teamID == 0 {
 		return nil
 	}
-	if mode != UnionSplit {
-		return []TeamShare{{TeamID: e.primaryTeamID(), Weight: 1}}
-	}
-	return normalizeShares(shares)
-}
-
-// normalizeShares 把份额归一化到总和 1，避免配置里权重不标准导致总分被放大。
-func normalizeShares(shares []TeamShare) []TeamShare {
-	var sum float64
-	for _, s := range shares {
-		sum += s.Weight
-	}
-	out := make([]TeamShare, len(shares))
-	if sum <= 0 {
-		w := 1 / float64(len(shares))
-		for i, s := range shares {
-			out[i] = TeamShare{TeamID: s.TeamID, Weight: w}
-		}
-		return out
-	}
-	for i, s := range shares {
-		out[i] = TeamShare{TeamID: s.TeamID, Weight: s.Weight / sum}
-	}
-	return out
+	return []TeamShare{{TeamID: teamID, Weight: 1}}
 }