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。

docs/部署指南.md

@@ -32,11 +32,11 @@ deploy\build.bat
 | 产物 | 类型 | 说明 |
 | --- | --- | --- |
 | `dist\scoreboard.exe` | 服务端 | 前端已通过内嵌方式打进可执行文件，单独运行也能提供全部页面 |
-| `dist\console\Scoreboard Console-0.1.1-x64.exe` | 安装包 | NSIS 安装程序，双击按向导安装 |
-| `dist\console\Scoreboard Console-0.1.1-x64.zip` | 免安装包 | 解压即用 |
+| `dist\console\Scoreboard Console-<版本>-x64.exe` | 安装包 | NSIS 安装程序，双击按向导安装 |
+| `dist\console\Scoreboard Console-<版本>-x64.zip` | 免安装包 | 解压即用 |
 | `dist\console\win-unpacked\` | 目录 | 未压缩的运行目录，便于现场调试 |
 
-> 版本号来自仓库根的 `VERSION` 文件：构建时由 `deploy\build.bat` 注入服务端二进制（`-ldflags -X main.version`，运行期不再读任何文件），并同步到 `console\package.json` 决定安装包/免安装包的文件名。**当前版本 `dev_0.1.1`**，在管理端「关于」页与 `GET /api/health` 里都能看到（没走构建脚本直接 `go build` 时兜底显示 `dev`，不编造版本号）。升级版本只改 `VERSION` 一处；以 `dist\console\` 下的实际文件名为准。
+> 版本号来自仓库根的 `VERSION` 文件：构建时由 `deploy\build.bat` 注入服务端二进制（`-ldflags -X main.version`，运行期不再读任何文件），并同步到 `console\package.json` 决定安装包/免安装包的文件名。**本文不写死版本号——以仓库根 `VERSION` 与 `dist\console\` 下的实际文件名为准**，运行期可在管理端「关于」页与 `GET /api/health` 里看到（没走构建脚本直接 `go build` 时兜底显示 `dev`，不编造版本号）。升级版本只改 `VERSION` 一处。
 >
 > 目标机器**不需要** Go / Node / pnpm，也不联网；上述工具只用于构建机。
 >
@@ -48,7 +48,7 @@ deploy\build.bat
 
 ### 3.1 使用安装包
 
-1. 双击 `Scoreboard Console-0.1.1-x64.exe`。
+1. 双击 `Scoreboard Console-<版本>-x64.exe`（版本以 `dist\console\` 下实际文件名为准）。
 2. 按向导选择安装目录（可自定义）。
 3. 安装完成后，桌面会出现名为**「赛事积分榜」**的快捷方式。
 4. 双击「赛事积分榜」启动。
@@ -57,7 +57,7 @@ deploy\build.bat
 
 ### 3.2 使用免安装包
 
-1. 把 `Scoreboard Console-0.1.1-x64.zip` 解压到任意目录（建议使用纯英文路径）。
+1. 把 `Scoreboard Console-<版本>-x64.zip`（版本以 `dist\console\` 下实际文件名为准）解压到任意目录（建议使用纯英文路径）。
 2. 双击目录里的 `Scoreboard_Console.exe` 启动。
 
 ### 3.3 首次启动会自动完成
@@ -111,7 +111,7 @@ deploy\build.bat
 
 - Console 启动时会把这个目录用 `-data` 参数交给服务端，界面上方「运行日志」里能看到 `数据目录：...` 这一行；
 - **服务端日志也在数据目录下**：`<数据目录>\logs\` 里分 `operations\`（放行类）与 `interceptions\`（拦截类）两个子目录，按天 + 按大小轮转、自动清理旧文件，可用 `config.yaml` 的 `log:` 段改位置与保留份数（见第 10 节）。它在安装目录之外，覆盖安装不会丢；
-- **上传资源随赛事项目走**：赛事会标、大屏背景图、单位 logo，以及「赛事信息 → 字体」里上传的**字体文件**，都在 `<数据目录>\event_projs\<项目名>\uploads\` 里（字体在 `uploads\fonts\`）。它们是文件而不是数据库记录，**不在 `backups\` 的 `.db` 快照里**，备份 / 迁移时要连这个目录一起拷（见 8.5、8.6）；
+- **上传资源随赛事项目走**：赛事会标、大屏背景图、单位 logo，以及「赛事信息 → 字体」里上传的**字体文件**，都在 `<数据目录>\event_projs\<项目名>\uploads\` 里（字体在 `uploads\fonts\`）。它们是文件而不是数据库记录，**不在 `backups\` 的 `.db` 快照里**（`.db` 快照与「一键恢复」都只动数据库，不含这些文件）；备份 / 迁移时要连这个目录一起拷（见 8.5、8.6）。构建/开发机上的 `deploy\backup.bat` 会额外把每个项目的 `uploads\` 打成 `*-uploads-<时间戳>.zip`，但那份 zip 不在服务端的 20 份滚动保留里，要手工清理；
 - **一次性迁移**：如果新数据目录还是空的，而旧的 `<安装目录>\data` 里有数据，Console 会在启动时把旧目录**整体改名**过去（同盘很快），日志里会写「已把旧数据从 X 迁移到 Y」。任何失败（跨盘、权限不足等）都只记日志，旧数据原地保留，不会被删；
 - 如果两个目录里**都有数据**，Console 不做任何动作，只写一条警告日志，由现场人工决定保留哪一份；
 - 迁移只在安装包版本（打包后）执行一次，`pnpm start` 之类的开发运行不会碰仓库里的 `data\`；
@@ -140,7 +140,7 @@ deploy\build.bat
 - 某一处建不出来或不可写（权限、杀毒软件拦截等）时**只记日志并回落到安装目录里那份**，绝不因此启动失败；代价是那份改动仍会在覆盖安装时丢失，日志里会明确写出来；
 - 开发运行（`pnpm start`）不接管这三项，仍用仓库里的 `console\config.json`、`config.yaml`、`rules\`；
 - 不用 Console、直接双击 `scoreboard.exe` 时，服务端仍按工作目录下的 `config.yaml` 读配置，**不受这套保护**；
-- 上传的图片与字体不在这三项里，位置见 3.4：它们随赛事项目存放在数据目录的 `event_projs\<项目名>\uploads\`（字体在 `uploads\fonts\`），同样在安装目录之外，覆盖安装不会动它们；**但它们不在 `backups\` 的数据库快照里**，备份 / 迁移时要连这个目录一起拷（见 8.6）。
+- 上传的图片与字体不在这三项里，位置见 3.4：它们随赛事项目存放在数据目录的 `event_projs\<项目名>\uploads\`（字体在 `uploads\fonts\`），同样在安装目录之外，覆盖安装不会动它们；**但它们不在 `backups\` 的数据库快照里**（「一键恢复」也只换数据库文件，不会带回图片），备份 / 迁移时要连这个目录一起拷（见 8.6）。
 
 > 从老版本覆盖升级上来的第一次启动：安装目录里那三份在覆盖安装时**就已经被旧卸载器删过一遍**（新装进去的是新版模板），Console 只能把模板复制到用户目录，升级前改在安装目录里的配置需要重做一遍。**从本版本起**（也就是改动落在上表位置之后），配置与规则才会跨升级保留。
 
@@ -406,7 +406,7 @@ http://<主机IP>:19540/display
 
 ### 8.1 备份目录
 
-所有备份都在**数据目录**下的 `backups\` 里，文件名为 `.db` 快照。默认数据目录是 `%LOCALAPPDATA%\ScoreboardConsole\data`，所以备份在：
+所有备份都在**数据目录**下的 `backups\` 里，主体是 `.db` 快照；用 `deploy\backup.bat` 时还会多出 `*-uploads-*.zip`（上传图片与字体）。默认数据目录是 `%LOCALAPPDATA%\ScoreboardConsole\data`，所以备份在：
 
 ```
 %LOCALAPPDATA%\ScoreboardConsole\data\backups\
@@ -421,18 +421,27 @@ http://<主机IP>:19540/display
 | 自动 | 服务端启动后按 `backup.intervalMinutes`（默认 5 分钟） | `system-auto-<时间戳>.db` 与 `event-auto-<时间戳>.db` |
 | 管理端 | 「系统设置 → 备份 → 立即备份」 | `system-manual-<时间戳>.db` 与 `event-manual-<时间戳>.db` |
 | 命令行 | 在安装目录执行 `scoreboard.exe backup -config "%LOCALAPPDATA%\ScoreboardConsole\config.yaml" -data "%LOCALAPPDATA%\ScoreboardConsole\data"` | `system-manual-<时间戳>.db` 与 `event-manual-<时间戳>.db` |
-| 快捷脚本 | `deploy\backup.bat`（原因记 `manual`）或 `deploy\backup.bat publish`（原因记 `publish`） | 同上（`publish` 时原因为 `publish`） |
+| 快捷脚本 | `deploy\backup.bat`（原因记 `manual`）或 `deploy\backup.bat publish`（原因记 `publish`） | 同上（`publish` 时原因为 `publish`）；**额外**把每个赛事项目的 `uploads\`（图片 + 上传字体）打成 `<项目名>-uploads-<时间戳>.zip` |
 | 发布前 | 每次发布成绩时自动 | `event-publish-<时间戳>.db` |
 
 - 备份使用 SQLite 的 `VACUUM INTO`，服务运行中也能安全执行，不需要停服务，也不依赖外部 `sqlite3.exe`；
 - 自动、手动、命令行三种方式都按 `backup.keep`（默认 20 份）滚动保留，`system` 库与赛事库各自计算，超出的旧备份自动删除；
+- ⚠️ **`*-uploads-*.zip` 不在 20 份滚动保留范围内**（滚动只认 `.db`）：它不会被自动清理，需要手工删旧文件（建议每个项目至少留最新一份）。`deploy\backup.bat` 不归档日志（`logs\`），排查材料要单独拷；空的项目 `uploads\` 会跳过，不产空包；
 - 同一时刻只允许一个备份在进行，自动备份与手动、发布前备份不会互相踩；
 - `deploy\backup.bat` 会自动用和 Console 相同的配置与数据目录（配置优先 `%LOCALAPPDATA%\ScoreboardConsole\config.yaml`、数据优先 `%LOCALAPPDATA%\ScoreboardConsole\data`，即用户数据目录里那两份；都不存在时回退到脚本上级目录 `..\config.yaml` 与 `..\data`），并分别作为 `-config` / `-data` 传给服务端，所以从哪里运行都不会备份到别的库；
 - 现场建议：开幕前、每次发布高峰前、每天结束时各手动备份一次（自动备份只是兜底）。
 
 ### 8.3 如何恢复
 
-服务端目前**没有一键恢复接口**，恢复需停机手工执行：
+**首选：管理端「一键恢复」（仅管理员）。** 到「系统设置 → 备份」，在备份列表里找到要退回到的那一份（列表会显示时间、原因、大小；`pre-restore-…` 是恢复前自动留的安全副本），点该行的**「恢复」**：
+
+1. 先过危险确认框（会写明要覆盖的是系统库还是赛事库、会丢弃备份时间点之后的改动）；
+2. 服务端先**给当前库拍一份「恢复前安全副本」**（`pre-restore-<库>-<时间戳>.db`，不参与 20 份滚动清理，选错时间点还能用它退回），再替换库文件，然后**优雅退出并由 Console 自动拉起**；
+3. 页面显示「正在重启服务端…」并自动等待刷新（最多 60 秒；超时就打开服务管理窗口确认状态后手动刷新）；
+4. **恢复是覆盖式的**：备份时间点之后的所有改动都会丢。恢复系统库还会连**账号与会话**一起换掉，重启后需要用那个时间点的账号重新登录；
+5. ⚠️ **恢复不会带回上传的图片与字体**（它们在 `uploads\` 里是文件，不在 `.db` 内）；需要一起回退时见 8.6。
+
+**没有 Console 或恢复不了时的兜底：停机手工替换文件。**
 
 1. 在 Console 里**停止服务**，避免恢复过程中继续写入；
 2. 把当前的 `<数据目录>\event_projs\<项目名>\event.db` 改名留档，确认恢复失败还能退回；
@@ -442,7 +451,7 @@ http://<主机IP>:19540/display
 
 > `<数据目录>\system.db` 保存账号与会话信息，一般不需要回退；如需一并回退，替换它的方法与 `event.db` 相同（同时删除 `system.db-wal` / `system.db-shm`）。
 >
-> 恢复会丢弃备份时间点之后的所有改动。现场若还有备机，优先切换备机比原地恢复更快。
+> 现场若还有备机，优先切换备机比原地恢复更快。
 
 ### 8.4 整机迁移
 
@@ -496,7 +505,7 @@ http://<主机IP>:19540/display
    - 拷到**别的路径**：先建好目标目录并放入数据，再在用户配置 `console\config.json` 里把 `server.dataDir` 指向它，重启 Console；
 4. 恢复完成后在管理端核对赛事、账号、上传图片与字体是否齐全。
 
-> 只拷 `backups\` 里的 `.db` 快照也能救回成绩数据，但上传的背景图/会标/单位 logo **与自定义字体**在 `event_projs\<项目名>\uploads\` 里（字体在 `uploads\fonts\`），不拷这个目录会丢这些文件，大屏上表现为图片不显示、字体回落成默认字体。
+> 只拷 `backups\` 里的 `.db` 快照也能救回成绩数据，但上传的背景图/会标/单位 logo **与自定义字体**在 `event_projs\<项目名>\uploads\` 里（字体在 `uploads\fonts\`），不拷这个目录会丢这些文件，大屏上表现为图片不显示、字体回落成默认字体。`deploy\backup.bat` 会自动把每个项目的 `uploads\` 打成 `*-uploads-*.zip` 放在 `backups\` 里（见 8.2），可以用它替代手工拷贝——但那个 zip **不参与 20 份滚动清理**，解压后请把项目目录里的 `uploads\` 覆盖回去，并定期手工删旧的 zip。
 
 ### 8.7 基础数据包导出 / 导入（单位 / 大项 / 小项 / 组别）
 
@@ -509,7 +518,7 @@ http://<主机IP>:19540/display
 
 - **按编码匹配，存在就更新、不存在就新建；绝不删除**：文件里没有的行不会被删，也不会被停用；
 - **两步走**：先「预览差异」（新增 / 更新 / 无变化 / 错误 + 逐行变化，这一步不写库），确认后再点「**确认写入**」；**有错的行会跳过，合法的行照常写入**，行级错误带**真实 Excel 行号**（如 `单位 第 3 行：单位编码必填`）；
-- **列不在表里 = 不动该字段**；**列在表里但格子空**：文本列与年龄上下限清空，权重按 1、布尔列按「是」，**排序留空保持原值**；
+- **列不在表里 = 不动该字段**（**布尔列也一样**：缺整列不等于「取默认值」，否则把「启用」列删掉再导回，会把所有停用的单位/大项静默改成启用）；**列在表里但格子空**：文本列与年龄上下限清空，权重按 1、布尔列按「是」，**排序留空保持原值**（**四张表口径一致**，单位 / 大项留空同样不会被改写）；
 - 表头行在第 4 行（系统导出件，上面是标题与副标题）或第 1 行（手工整理的表）都能识别；枚举列要填英文规范值（如 `individual` / `time` / `published`），布尔列填「是 / 否」；
 - 被「彻底删除」的单位不在导出件里，导入也**不会**把它翻出来（仍是隐藏状态）；
 - **这个包只含基础数据**，不含成绩、报名与规则；整场赛事的搬迁仍用赛事项目包（见 8.5）。赛前导出一份留底，现场改乱了可以导回对照。