fix(m168): 复审 r3 四项 —— 说准 panic 档、给两条修复补守卫、时限算术补洞

复审 r3（p2-4items / fix-then-merge）四项 + 顺手五条：

1. **P2-1 `catch_unwind` 在发布档是死代码，三处文档说了不成立的话**：
   `Cargo.toml` 的 `[profile.release]` 是 `panic = "abort"`（只有 `fast` 是 `unwind`），发布走
   `--release`。分两半写清楚：①**闸前移仍安全**——release 档 panic 是进程退出，不存在永久停在
   `Downloading`；`dev`/`test`/`fast` 档 `catch_unwind` 真会写 `Failed`；②但「下载失败不崩」在
   panic 这一支上对发布版**是反的**：注册/`load_font` panic ⇒ 启动器整体 abort，不是降级。
   `install.rs::plan_with_offline` 的文档（新增两档对照表）、`worker.rs` 模块文档与 `run` 注释全部
   按这个说法重写，不再用 `catch_unwind` 给「不崩」背书。

2. **P2-2 「启动不发起下载」这条修复没有守卫**：拆出纯函数
   `fonts::resolve_with_faces(setting, faces)`（`resolve_with` 只是 `system_faces()` 的包装），
   新增 `fonts::tests::resolving_fonts_never_starts_a_download`：给一张只有拉丁族的脸表
   （一定判 `NeedsDownload`），断言调用后 `install::status()` **不是** `Downloading`。
   变异（实跑）：把 `install::after_probe(cjk_report.strategy)` 加回 `resolve_with_faces` ⇒
   `求值字体**不许**发起下载（状态从 Unknown 变成了 Downloading { bytes: 17772300 }）`，红。

3. **P2-3 时限算术有洞 + `is_last` 没守卫**：改 `ATTEMPT_DEADLINE=60 s` / `TOTAL_DEADLINE=420 s`
   （原来 120/360 时，第一个候选吃掉 120 s 后最后一个只剩 240 s ⇒ 门槛 72.3 KiB/s，r1 实测
   67 KiB/s 需要 259 s，仍然必失败）。文档按新数值重算成一张表：第一个候选瞬间失败 ⇒ 420 s ⇒
   42.3 KiB/s；爬满 60 s 被切 ⇒ 360 s ⇒ 49.4 KiB/s，两者都低于实测最慢的 67 KiB/s。
   守卫：把同解的旧用例换成 **单候选 + attempt 300 ms / total 5 s**——有 `is_last` 时跑到总时限
   （≈5 s），没有时 300 ms 就切，两种实现可分辨。变异（实跑）：删掉 `is_last` ⇒
   `the_last_candidate_gets_the_whole_remaining_budget` 红在
   `最后一个候选该拿整个剩余预算（≈5 s）…452.6035ms`。

4. **P2-4(b)(c)**：①`install::tests` 里三处判据用例改用 `plan_with_offline(..., false)`，把进程级
   `OFFLINE` 从判据里摘出去（否则同进程里 `headless(screenshot_options())` 会把它置 true 且从不
   还原 ⇒ 结果依赖执行顺序）；②`fonts.rs` 注释改成真实机制——出图 harness 不经
   `App::with_presenter`、压根没有 `set_offline`，它零流量靠的是「`resolve_with` 不触发」。

顺手：①`sha256_mismatch…` 的 doc 改成「两层校验互备，本用例抓的是两层同时拆」（原来说
「拆任意一层就红」是假的）；②`font.rs` 文档「把 90 s 压成 300 ms」→ 60 s/420 s；③`install.rs` 与
`catalog/font_install.rs` 的「≈17 MB」→ 16.9；④`worker::start` 的裸 `thread::spawn` 换成
`Builder::spawn`，起不来就落 `Failed`（发布档 panic = abort，不能让它 panic）；线程体抽成 `run()`。

验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，取退出码、不截断）：
- `cargo test -p unlucky-app-iced --lib` → **688 passed / 0 failed / 2 ignored / exit 0**
- `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0**
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0
- `cargo fmt --all -- --check` 干净；全仓无文件 >400；本轮改动文件最大 378（`app-iced/src/fonts.rs`）

crates/app-iced/src/fonts/install.rs

@@ -21,7 +21,7 @@
 //!
 //! ## 为什么下载在后台线程而不是启动那一拍
 //!
-//! 一份 17 MiB 的字体在弱网下要几十秒。启动编排（`app/boot.rs`）是在**开窗之前**同步跑的，
+//! 一份 16.9 MiB 的字体在弱网下要几十秒。启动编排（`app/boot.rs`）是在**开窗之前**同步跑的，
 //! 在那里下载等于「点了图标，窗口几十秒不出来」。所以：启动路径只**发起**，窗口照常起来，
 //! 状态行（设置页 General 组）与 stderr 日志承担「正在获取 / 完成 / 失败」这三句话。
 //!
@@ -97,7 +97,7 @@ pub enum CjkInstall {
     Unprobeable,
     /// 正在下载。
     Downloading {
-        /// 字节数（pin 里的期望值；用来写「≈17 MB」这种可核对的量）。
+        /// 字节数（pin 里的期望值；用来写「16.9 MB」这种可核对的量）。
         bytes: u64,
     },
     /// 已就绪（下载完成并注册进字体系统）。
@@ -263,8 +263,18 @@ pub enum Step {
 /// 会走 `Apply(Unprobeable)` —— 把状态从「正在下载」改回「无法探测」，而**线程还在飞**：
 /// 下完之后 `Ready` 又把它盖回去，状态行在 30 秒里来回翻。当时给出的理由是「否则界面会停在
 /// 正在下载」——那个理由只对**僵死**的 `Downloading` 成立（线程 panic 才会僵死），而在飞是
-/// 常见情形。僵死那一半现在由 worker 的 `catch_unwind` 兜底（任何 panic 都会写终态），
-/// 所以「下载中一律 Skip」不再有卡死的风险。
+/// 常见情形。
+///
+/// ## 「僵死」那一半按构建档分两说（复审 r3 P2-1，别再当成一条统一的兜底）
+///
+/// | 档 | panic 语义 | 线程 panic 之后 |
+/// |---|---|---|
+/// | `release`（`Cargo.toml` 的 `panic = "abort"`，发布就走它） | 进程直接 abort | 不存在「停在 Downloading」，因为**进程没了**；反过来说「下载失败不崩」在 panic 这一支上对本档**不成立**（注册路径 panic ⇒ 启动器整体死掉，不是降级） |
+/// | `dev` / `test` / `fast`（unwind） | 栈展开 | `worker` 的 `catch_unwind` 把状态写成 `Failed`，闸因此不会卡死 |
+///
+/// 也就是说：**闸前移在两种档下都安全**（release 靠「进程退出」，unwind 档靠 `catch_unwind`），
+/// 但 `catch_unwind` **不能**用来给「下载失败不崩」背书——它只在 unwind 档存在。字体注册路径的
+/// panic 在发布版仍会让启动器 abort，这是本 mission 未解决的一项（报告里列为未验/风险）。
 ///
 /// `offline = true`（出图通道）时**永不** `Start`：D30 要求同一份代码出同一张图，而下载会额外
 /// 产生网络流量并可能在出图过程中注册新字体。
@@ -294,7 +304,7 @@ pub fn plan(strategy: Strategy, current: &CjkInstall) -> Step {
 
 /// 判据结论 → 现在这一步的结局（生产入口；判据全在 [`plan`]，这里只执行）。
 ///
-/// * 已经在下载 / 已就绪 → 什么都不做（幂等：切一次语言不会起第二条下载、不会重复注册 17 MiB）；
+/// * 已经在下载 / 已就绪 → 什么都不做（幂等：切一次语言不会起第二条下载、不会重复注册 16.9 MiB）；
 /// * 英文环境 / 系统已有 / 探测不出 → 只更新状态（零网络）；
 /// * 上次失败过 → 只有再次切语言才会重试（用户显式动作），不会自己反复联网；
 /// * 出图通道（[`set_offline`]）→ 永不发起。
@@ -315,7 +325,7 @@ pub fn after_probe(strategy: Strategy) -> CjkInstall {
 /// 本进程是否**禁止**发起字体下载（出图通道用；D30：同一份代码出同一张图）。
 ///
 /// 为什么需要它：截图/演示通道也会走 `App` 构造 → `lang.log_cjk()` → `cjk_for` → `after_probe`。
-/// 一台 zh-locale、没有中文字体的机器上，出图会真的下 17 MiB 并在出图过程中注册新字体——
+/// 一台 zh-locale、没有中文字体的机器上，出图会真的下 16.9 MiB 并在出图过程中注册新字体——
 /// 这既产生流量，也让「同一份代码出同一张图」不再成立。
 pub fn set_offline(offline: bool) {
     OFFLINE.store(offline, std::sync::atomic::Ordering::Relaxed);