fix(packaging): 修复 Windows 安装与固件打包并完善客户端文案

- fix(installer): 修复低完整性产物无法写入临时目录的问题，并在 CI 打包前后检查完整性标签
- fix(firmware): 从本次 Cargo ELF 打包并同步配套镜像，修正短目录说明与 LLVM 搜索顺序
- fix(installer): 修复中文完成页和页眉遮挡，侧栏使用等比缩放的原始 Logo
- style(client): 应用图标增加圆角，统一“裁判系统客户端”命名
- fix(config): 安装提示改用可选本地热点配置，排除 Wi-Fi 凭据
- docs: 润色项目说明并统一裁判系统术语
- test(packaging): 补充 Windows 完整性和固件打包回归，覆盖外部输出目录、旧镜像与重复生成

验证：Windows NSIS 构建及原生页面预览；通用与本地安装配置编译；固件 release 构建、重复打包和客户端离线校验；6 项固件打包回归与 Windows 权限回归；git diff --check。未执行实机烧录。

docs/maintenance/firmware.md

@@ -13,8 +13,7 @@
 
 ## 为什么坏块规避不需要重编译
 
-App 镜像不包含自己的分区偏移；偏移只在 `0x8000` 的分区表里。所以同一份 App 可以
-写到旧 App 之后的空闲槽位，只需要改分区表里的 factory 偏移，不需要重新构建。
+App 镜像不包含自身的分区偏移，偏移保存在 `0x8000` 的分区表中。因此，同一份 App 可写入旧 App 之后的空闲槽位，只需修改分区表中的 factory 偏移，无需重新构建。
 
 旧 `scripts/flash.sh` 之所以重编，是因为它把新偏移写回 `partitions.csv` 再重建。
 客户端直接修改从设备读取的当前分区表；包内的 `partition-table.bin` 只作参考模板与校验：
@@ -50,8 +49,7 @@ App 镜像不包含自己的分区偏移；偏移只在 `0x8000` 的分区表里
 - `0xFADE7`：bit 5–7 无法正确编程（已确认）；
 - `0x10863`：bit 6 读回为 1，尚未确认是否为永久故障，见[硬件说明](../hardware/camera.md#损坏-flash-模组的兼容处理)。
 
-两个地址都在 `0x100000` 以下；`0x200000` 槽位天然避开它们。客户端仍会对写入的
-App 整段回读，不依赖“已知坏点表”。
+两个地址均低于 `0x100000`，因此 `0x200000` 槽位避开了它们。客户端仍会整段回读写入的 App，不依赖“已知坏点表”判断是否成功。
 
 ## 官方 .zip 固件包
 
@@ -104,7 +102,9 @@ BUILD-INFO.json       # 可选；展示版本/构建信息
 编译后打包：
 
 ```powershell
-# 只打包（会先调用 make_bundle.py 刷新 bundle.json）
+# Windows：使用与构建时相同的短目录。
+$env:CARGO_TARGET_DIR = 'C:\s3vt'
+# 只打包（从 ELF 导出镜像，再调用 make_bundle.py 刷新 bundle.json）
 python scripts/package_firmware.py --firmware target/firmware
 
 # 构建完成后自动打包
@@ -115,13 +115,13 @@ scripts/build.sh --package
 产物：
 
 ```text
-target/firmware/camfw-<chip>-<variant>-<rev>-<yyyymmdd>.zip
+target/firmware/camfw-<chip>-v<version>-<build>.zip
 target/firmware/camfw-...zip.sha256
 ```
 
-zip 使用固定条目顺序、固定 mtime 与 deflate level 9，同一个输入应得到同一个整包
-SHA256，便于核对分发的固件包是否一致。`package_firmware.py` 会复用
-`make_bundle.py`，不维护第二套 manifest 逻辑。
+zip 使用固定条目顺序、固定 mtime 和 deflate level 9。同一输入应生成相同的整包 SHA256，便于核对分发的固件包是否一致。`package_firmware.py` 复用 `make_bundle.py`，无需另维护一套 manifest 逻辑。
+
+PowerShell 构建入口通过 Cargo 的产物报告传递 ELF 路径；单独运行 Python 打包时，通过 `cargo metadata` 读取输出目录，支持 `CARGO_TARGET_DIR` 和 Cargo 的 `build.target-dir`。也可用 `--elf <路径>` 显式指定 ELF。脚本从该 ELF 导出 App，复制同目录的 Bootloader 和分区表，并重写构建信息，避免沿用旧镜像或旧实机测试结论。缺少 ELF、配套镜像或导出工具时默认停止；仅在明确需要复用现有目录包时使用 `--allow-stale`。版本默认读取根目录 `version.json`。切回桌面端构建前执行 `Remove-Item Env:CARGO_TARGET_DIR`。
 
 > 注意：bundle 里的 `partition-table.bin` 是参考模板；客户端实际写的是设备当前
 > 分区表的 patch 版本，以保留设备的 NVS/PHY 布局。bundle 的分区表 SHA 仍会校验。
@@ -219,10 +219,7 @@ Secure Boot / Flash Encryption 均未启用）上验证：
 - 离线单元测试：分区表解析、MD5 重算、候选槽位、尺寸解析、zip 路径白名单，共 7 个；
 - 前端 `tsc --noEmit`、`vite build`，后端 `cargo check` 通过。
 
-**尚未执行**完整实机切换（写 patch 后分区表 → 复位 → 启动日志）。App 写入/回读
-已经在同一块板上验证；切换步骤的风险集中在 0x8000 的 3 KiB 分区表写入，写入后会
-回读，失败会尝试恢复旧表。如果新 App 启动失败，页面会给出
-备份目录和 `恢复旧分区表` 按钮。
+完整实机切换（写 patch 后分区表 → 复位 → 启动日志）尚未执行；App 写入和回读已在同一块板上验证。切换风险集中在 0x8000 处的 3 KiB 分区表写入，写入后会回读校验，失败时尝试恢复旧表。若新 App 启动失败，页面会显示备份目录和 `恢复旧分区表` 按钮。
 
 ## 边界