fix(m204): Java 组写盘成功后请 host 重发设置快照

`pages/settings/java/store.rs` 的 `save()` / `set_selected()` / `prefs_store::save()`
是页面自己的一次同步原子落盘（`SettingStore::set` 多个键 + 一次 `save()`），
不经过 `AppCommand::SetSetting` 的写盘分支；而 `CoreEvent::SettingsChanged`
全仓只有 `dispatch.rs` 的 `SetSetting` 分支与 `host/mod.rs::refresh_all` 两处发出。
于是三键写成功之后，`AppState::settings_groups` 里 java 组那几行会停在旧值，
直到下一次任何别的写入顺手带一份新快照回来。

修法用一条**动作键**（`dto::JAVA_REFRESH_ACTION` = `java.action.refresh`，
与 `download.action.detect_region` 同一族：不写盘、见到就返回 Ok）：
写盘成功后派发它，`SetSetting` 分支照常重发快照。

不用 `RefreshAll`：那个除重发快照之外还会 `versions::spawn_list` 与
`start_update_check`——每点一次「保存内存」打两个网络请求（实测：一次真 host 出图
就在数据根里落了 `cache/meta/version_manifest_v2.json`），代价与动作不相称。

另外给 D30 §2.1 补一行自证身份的日志：`--screenshot` 且身份变化时打
`[shot] settings route=… group=… theme=…`（`view` 每帧都跑，所以只在变化时落一行），
免得再出现「拿外观页当下载组证据」那种图与结论对不上的事故。

守卫（`tests/java_refresh.rs`，4 条）：
- 真 `CoreHost` + 临时数据根跑完整链：写盘 ⇒ 快照里 `java.extra_args` 真的变了；
- 被拒的保存不许请求刷新；
- 成功之后确实派发了那条动作键（键名写错就红）；
- 「立即扫描」在 App 层真的接线（此前没有任何用例驱动 `Message::Scan`）。

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

@@ -30,6 +30,44 @@ use instances::{detail_of, runtime_status_row, supporting_line};
 use logs::logs_model;
 use update::update_of;
 
+/// 上一次记过的「设置页看到的组 + 主题」（`None` = 还没记过）。
+///
+/// 只给 [`note_screenshot_group`] 用：`view` 每帧都会跑，日志必须只在身份**变化**时落一行。
+/// 用 `Mutex` 而不是 `AtomicUsize` 位打包：主题是字符串（`ull-m3-light` / `ull-m3-dark`），
+/// 把两件事挤进一个整数要引入「高半位 = 深色」这种与主题命名耦合的约定，不如老实用一对值。
+static SHOT_GROUP_LOGGED: std::sync::Mutex<Option<(usize, String)>> = std::sync::Mutex::new(None);
+
+/// D30 §2.1 的「哪一行日志证明它是哪个组/主题」：出图通道专用的一行身份日志。
+///
+/// ## 为什么必须有
+///
+/// 举证图自带不了身份。M201 的事故就是 worker 交了一张「外观」页当下载组的证据，报告里的结论
+/// 建立在一个错的「这是哪个组」上，直到视觉 reviewer 自己重拍才发现。所以每张交付图都要能对上
+/// 一行日志：`[shot] settings route=Settings group=2 theme=ull-m3-light`。
+///
+/// ## 为什么只在变化时打
+///
+/// `App::view` 每帧都调用；每帧一行会把 `launcher.log` 刷满，反而没人能从中找到那一行。
+/// 判据是（组序号，主题名）这一对——同一次截图进程里最多两行（首帧 + 主题切一次）。
+/// 拿不到锁（另一个线程正在写）就**不打**：身份日志宁可少一行，也不能把界面帧卡在锁上。
+///
+/// **非截图通道一律不打**：交互模式下用户每点一次左列就多一行日志，没有价值。
+fn note_screenshot_group(screenshot: bool, route: &Route, group: usize, theme: &str) {
+    if !screenshot {
+        return;
+    }
+    let Ok(mut last) = SHOT_GROUP_LOGGED.lock() else {
+        return;
+    };
+    let seen = (group, theme.to_string());
+    if last.as_ref() == Some(&seen) {
+        return;
+    }
+    *last = Some(seen);
+    drop(last);
+    crate::app::diag::diag!("[shot] settings route={route:?} group={group} theme={theme}");
+}
+
 impl App {
     /// 主题名（iced 只在 `Theme::name()` 变化时重算受主题影响的缓存）。
     pub(super) fn theme(&self) -> Theme {
@@ -45,6 +83,18 @@ impl App {
     pub(super) fn view(&self) -> Element<'_, Message> {
         log_first_frame();
 
+        // D30 §2.1：出图通道要有一行能**自证身份**的日志——「这张图是哪个设置组、哪个主题」。
+        // 上一次 M201 的事故就是拿外观页当下载组的证据；图不自证身份，结论就无处落地。
+        // 只对设置页打（左列那几组才有「哪个组」这件事）。
+        if self.state.route() == &Route::Settings {
+            note_screenshot_group(
+                self.options.screenshot.is_some(),
+                self.state.route(),
+                self.appearance.selected_group,
+                self.ui().name(),
+            );
+        }
+
         // `--screen=gallery`：组件库 harness（D39 §5）。它用自己的 DemoMessage，
         // 这里只做一次 map，组件库与业务 Message 依然解耦。
         if self.options.screen == Screen::Gallery {