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/testing/realtime.md

@@ -2,11 +2,13 @@
 
 ## 当前交付
 
-当前 15 dBm 交付 App SHA-256：`a6092e4b0cf42819c04424e066651f285b8961312a73822d667532f800e46767`，应用分区 `0x70000`。COM8 烧录与三段独立校验通过；355.1 秒串口的 71 次功率回读均为 15.00 dBm。五分钟观察：原生完整接收 **29.68 fps**，丢帧 **1.045%**，本地 JPEG 通道 **28.23 fps**，31 张抽帧全部完整解码为 640×480 RGB，无无效 JPEG、设备离线、通道断开、复位或采集错误；仍有最长 1.646 秒的到帧间隔，不能称为无卡顿。距离与拥塞分析、测试边界见 [功率与拥塞记录](power.md) 和制品 `POWER-RESULT.json`。
+当前 15 dBm 交付 App 的 SHA-256 为 `a6092e4b0cf42819c04424e066651f285b8961312a73822d667532f800e46767`，应用分区为 `0x70000`。COM8 烧录与三段独立校验通过；355.1 秒串口记录中的 71 次功率回读均为 15.00 dBm。
+
+五分钟内，原生完整接收帧率为 **29.68 fps**，丢帧率为 **1.045%**，本地 JPEG 通道帧率为 **28.23 fps**。31 张抽帧均完整解码为 640×480 RGB；未发现无效 JPEG，也未出现设备离线、通道断开、复位或采集错误。但最长到帧间隔仍有 1.646 秒，不能称为无卡顿。距离与拥塞分析、测试边界见 [功率与拥塞记录](power.md) 和制品 `POWER-RESULT.json`。
 
 沿用已确认可用的三块 PSRAM 采集缓冲、OV5640 VGA 彩色、约 30 fps PLL 时钟、AE 目标 45/55、约 20 ms 曝光上限及自动增益；Wi-Fi 自动重连和 TUN 兼容订阅保持不变。没有增加待发送 JPEG FIFO，也没有为了消除队列改成单块 DMA 缓冲。
 
-发送程序只持有当前一张完整 JPEG；阻塞恢复后通过有限次数的零等待取帧选择最新有效帧，旧帧立即归还驱动。三块采集内存用于捕获余量，与必须按序播放的三帧队列不同。已有相机队列仍然有限，应用交接会跳过其旧帧。
+发送程序一次只持有一张完整 JPEG。阻塞恢复后，通过有限次数的零等待取帧选出最新有效帧，并立即将被替换的旧帧归还驱动。三块采集内存提供捕获余量，并非必须按序播放的三帧队列。相机队列仍有容量上限，应用交接时会跳过其中的旧帧。
 
 完整 JPEG 取得后按 1400 字节载荷分片立即提交，复用一个数据报缓冲，直接读取 PSRAM。当前传感器驱动在 JPEG 结束后交出完整帧，本次没有改成在 DMA 尚未完成时就读取其内容；不完整 JPEG 由接收端整帧丢弃，不进入绘制。
 
@@ -35,9 +37,9 @@ WIFI_TX_POWER_DBM=15
 
 若要在发送回压时立即放弃本帧，可将 `UDP_RETRY_BUDGET_US=0` 后重编烧录。该模式仍保留三块采集内存和完整 JPEG 校验；这里的“零”指不让出调度重试，不是删除驱动和路由器中的所有缓冲。零重试策略已经主机测试，本次五分钟实机使用默认 8000 μs。
 
-分片间隔也计入 25 ms 检查期限，不再额外延长帧的发送寿命；设置过大的间隔可能使整帧无法在期限内提交。分片在 SDK socket 中已经接受后无法由本策略撤回，底层调度和网络排队也无法由应用层强制抢占。以上为应用层新鲜度策略，不能保证每帧、无线链路或物理屏幕具有硬实时上限。
+分片间隔计入 25 ms 检查期限，不额外延长帧的发送寿命；间隔过大可能使整帧无法按期提交。SDK socket 已接受的分片无法由本策略撤回，应用层也无法强制抢占底层调度和网络排队。因此，这些新鲜度策略只能约束应用层，不能为每帧、无线链路或物理屏幕保证硬实时上限。
 
-本地 JPEG 二进制头继续为 16 字节，旧消费者可忽略新增文本消息。新前端连接旧后端时仍可用，但没有原生发布时间，只能按 JS 收到时刻判断本地队列年龄。两端本机发布时间使用同机系统时间；这不是 ESP 与电脑的时钟同步，也不能据此计算无线单向延迟。JS 内部排队同时使用单调时钟检查。
+本地 JPEG 二进制头仍为 16 字节，旧消费者可忽略新增的文本消息。新前端也可连接旧后端，但由于没有原生发布时间，只能按 JS 收到消息的时刻判断本地队列年龄。本地通道两端使用同机系统时间记录发布时间；这不涉及 ESP 与电脑的时钟同步，也不能用于计算无线单向延迟。JS 内部排队同时使用单调时钟检查。
 
 ## 此前 14 dBm 版本的实机五分钟检查