fix(m204): 补「扫描中/还没扫描过/正在取消」三格种子 + try_lock 说明对得上代码

视觉复审 r1 判 p2-1items：六张举证图里「取消」全程是禁用态，「正在扫描… 3/7」
一格都没拍，而 README 却写成「两态」——证据覆盖不到结论（与 M201 同一个坑）。
本提交补种子与拆文件，不出产品行为改动。

- `pages/settings/java/seed.rs`：新增 `scanning` / `unscanned` / `cancelling` 三档。
  三档都把快照写进 `ScanSlot`（新增 `ScanSlot::seed_report`）而不只改 `State.scanning`：
  `clock.advance` 每拍用槽里的快照重算 `scanning`，只改 State 的话第一拍就被推回「没在扫」。
- `pages/settings/java/scan.rs`：`ScanReport` / `Job` / `ScanSlot` / `run_staged` / `rows`
  从 `store.rs` 拆出（加 `seed_report` 之后那个文件 408 行，越过 400 行硬线）；
  `store.rs` 用 `pub use` 再导出 `ScanReport` / `ScanSlot`，既有路径一个都没改。
- `app/view.rs`：`note_screenshot_group` 的锁从 `lock()` 换成 `try_lock()`——代码复审 r1 指出
  注释写着「拿不到锁就不打、不能把界面帧卡在锁上」，而实现用的是阻塞 `lock()`，只兜住中毒
  不兜住等待。选 try_lock 而不是改注释：注释承诺的保证应由代码提供，不能靠「今天只有一个
  调用点、锁里只有一次比较」这种会随改动失效的前提。
- `pages/settings/java/tests/cmdline.rs`：新增 `the_scan_seeds_cover_the_running_states`，
  逐档钉 `State.scanning` 与 `scan.report().running`（后者才是「心跳下一拍会不会把它推开」）。

crates/app-iced/src/app/view.rs

@@ -49,14 +49,20 @@ static SHOT_GROUP_LOGGED: std::sync::Mutex<Option<(usize, String)>> = std::sync:
 ///
 /// `App::view` 每帧都调用；每帧一行会把 `launcher.log` 刷满，反而没人能从中找到那一行。
 /// 判据是（组序号，主题名）这一对——同一次截图进程里最多两行（首帧 + 主题切一次）。
-/// 拿不到锁（另一个线程正在写）就**不打**：身份日志宁可少一行，也不能把界面帧卡在锁上。
+///
+/// ## 为什么是 `try_lock` 而不是 `lock`
+///
+/// 这里在 UI 线程的每帧路径上。`try_lock` 拿不到锁就**直接返回**（这一帧不打，下一帧还会再来，
+/// 身份行只是晚一拍、不会丢），于是「界面帧永远不会被这把锁挡住」是**代码保证的**，不是靠
+/// 「今天只有一个调用点、锁里只有一次比较」这种会随改动失效的前提。M204 r1 复审把原先那句
+/// 「拿不到锁就不打」和当时用的阻塞 `lock()` 对上了：注释承诺的保证必须由代码提供。
 ///
 /// **非截图通道一律不打**：交互模式下用户每点一次左列就多一行日志，没有价值。
 fn note_screenshot_group(screenshot: bool, route: &Route, group: usize, theme: &str) {
     if !screenshot {
         return;
     }
-    let Ok(mut last) = SHOT_GROUP_LOGGED.lock() else {
+    let Ok(mut last) = SHOT_GROUP_LOGGED.try_lock() else {
         return;
     };
     let seen = (group, theme.to_string());