feat(m188): launcher.log 早落盘 + 会话日志搬到 logs/game（旧家只读兼容）

用户投诉原话：「我们的启动日志放在哪？…他找半天没找到崩溃日志」「只有一个安装日志」。

启动器运行日志（.ULL/logs/launcher.log）
- presenter 构造 HostEnv 时就登记日志目录：启动早期缓冲的 200 行（[probe]/[font]/[theme]）
  当场刷盘，不再是「只有开过一局游戏才有日志」。
- app/** 里所有 eprintln! 诊断改走 app::diag::diag!（stderr + 文件双写，行首 [tag] 即 scope），
  含 boot/boot::fallback/state/update 各线。
- boot 那一拍补一行后端事实（request/effective/fallback）。
- 滚动上限（1 MiB → launcher.1.log，只留一份）写进 README 与 docs/logs-location.md。

会话日志搬家：data/agent/sessions → logs
- LauncherLayout: sessions_root()/game_logs() 新增，agent_sessions() 降级为只读兼容。
- host/logs 与 cli/commands/sessions 两个根合并（同 id 新根优先），event_path 回落旧家。
- 不搬不删；日志目录写一份 session-log-location.json 记录（moved=0, policy=read-only-compat）。

入口与文案
- 设置页「通用」新增「日志文件夹」行：路径 + 打开目录 + 复制路径（i18n 中英）。
- 日志页页头的「打开目录」不再是占位：走 M187 的 open_dir，失败文本带路径并送进剪贴板。
- README.md / README.zh-CN.md 新增「日志在哪」章节（含 crash-reports 只在游戏走到那一步才有），
  docs/logs-location.md 给出上限、双写判据、迁移策略与没验的部分。

守门（每条都有变异证明，见报告）
- 旧家会话仍列得出/打不开 ⇒ 只读新根变红；新会话写 logs/game ⇒ 只读旧根、写回旧家都变红。
- launcher.log 滚动 ⇒ 干掉 rename 变红。
- 打开日志文件夹指向真实目录 ⇒ 换成 cache/ 或去掉 create_dir_all 都变红。
- 日志根随三模式变化 ⇒ 把 HostEnv::logs_dir 写死成便携落点变红。

crates/app-iced/src/app/update/boot_env.rs

@@ -31,15 +31,15 @@ pub(super) fn env_start_route() -> Option<Route> {
 ///
 /// `.ULL/logs` 的落点由 `platform::data_dir` 的三模式决定（要读配置、follow `redirect.json`），
 /// 那件事只有 presenter 的 `HostEnv` 做过。app 层拿不到它，于是这里只 `record`
-/// （core 侧缓冲，最多 200 行）；第一次启动时 presenter 调 `launcher_log::set_dir`，缓冲一次
-/// 刷进 `<.ULL>/logs/launcher.log`。
+/// （core 侧缓冲，最多 200 行）；presenter **构造 `HostEnv` 的那一刻**就调
+/// `launcher_log::set_dir`（M188 补上的那一半），缓冲一次刷进 `<.ULL>/logs/launcher.log`。
 ///
 /// 效果正是用户投诉要的那份东西：他「双击 → 启动 → 崩 → 找日志」时，`launcher.log` 里从
 /// **启动这一拍**（主题 / 语言 / 路由 / 窗口 / 后端）一直写到退出，而不是只有 launch 那一段。
 ///
-/// 边界（写在明处）：进程若一次都没启动游戏、又没触发导出，`set_dir` 就不会被调用，
-/// 这些行只留在内存里 → 那个进程不产生 `launcher.log`。要彻底解决得让 presenter 在构造
-/// `HostEnv` 时就登记目录（`host/mod.rs` 不在本 mission scope，已登记为 follow-up）。
+/// M188 之后边界也变了：`boot.rs` / `boot/fallback.rs` / `state/*` 那些 `eprintln!` 改走
+/// [`crate::app::diag::emit`]（stderr + 文件双写），同样靠这条缓冲接住——所以「一局都没开就崩」
+/// 的进程也会留下 `launcher.log`。
 pub(crate) fn record_boot_log(app: &super::super::state::App) {
     use unlucky_core::launch::launcher_log;
 
@@ -58,4 +58,15 @@ pub(crate) fn record_boot_log(app: &super::super::state::App) {
         ),
     );
     launcher_log::record("boot", &unlucky_cli::commands::msa_client_id_log_line());
+    // 后端这一拍也要在日志里：`[probe]` / `[backend]` 那几行由 `renderer::acceptance` 打到
+    // stderr（那个模块不在 M188 的 scope），事故之后翻日志的人至少要看得出「这次用的是哪个后端」。
+    launcher_log::record(
+        "boot",
+        &format!(
+            "backend request={} effective={} renderer_fallback={}",
+            app.options.backend.name(),
+            super::super::backend::effective_backend(app.options.backend).name(),
+            std::env::var(crate::renderer::FALLBACK_ENV).unwrap_or_else(|_| "-".to_string()),
+        ),
+    );
 }