AskaEth
a0413a5f94
feat(host): M302 实例列表刷新搬出 UI 线程（扫盘进后台 + 代次丢弃过期结果）
`refresh_instances()` 以前把「扫盘」与「盖回运行时态」写在一起，而 `dispatch(RefreshAll)`
那一支是唯一没走 `job::spawn` 的（邻座 ListVersions / ListLoaderVersions 都走了）⇒ 同步跑在
UI 线程：官方根 200 版本约 236 ms、叠加 10 份外部档案 1.35 s（仓库内旧实测 M297）。
两半分家：
- `game::instances(&env)` 是纯 env 函数 ⇒ 搬进 `job::spawn("instances", …)`，回程是新载荷
`HostTask::Instances { epoch, instances, elapsed_ms }`；
- 「按 `launches/pending/failed` 覆写 Running/Busy/Failed」要读 host 自己的表 ⇒ 留在 host 线程，
挪到结果回来那一刻（`handle::apply_instances`），结论与之前逐字一致。
顺序：每次刷新领一个只增不减的代次（`game::Scan`），只采纳当代次那份。并发两次刷新 / 扫描途中
删实例 / 收尾触发第三次这三种交错下，先发后到的扫描一律丢（不发事件：清空再重填只是把卡顿换成
白屏）。不做线程取消 —— 扫描是纯读，没有值得取消的东西，丢结果比掐线程安全。
可观测：每次采纳打一行 `[instances] N 个实例 · 扫盘 X ms · epoch E · 丢旧代次 D 份`，
丢弃也各打一行；账本 `game::Scan` 可直接断言（实例数 / 耗时 / 丢包数）。
判据（都真构造：真临时根 + 真 profiles.json + 真线程，只有交付顺序是摆的）：
- `a_refresh_returns_before_the_scan_is_done`（改回 inline 即红）
- `two_refreshes_in_flight_publish_only_the_newest`
- `an_older_scan_cannot_resurrect_what_a_newer_one_saw_deleted`
- `a_launch_end_refresh_beats_the_two_that_were_in_flight`
- app 侧 `a_refresh_in_flight_keeps_the_list_and_does_not_pin_the_clock`（不清空 + M298 的
view_dirty 不永久置真）
- `launch_state_tests` 的 5 处 `refresh_instances()` 后补一行 `pump_instances()`（断言一字未动）
2026-11-13 17:58:59 +08:00
..
2026-11-12 12:06:46 +08:00
2026-11-05 14:08:37 +08:00
2026-11-13 17:58:59 +08:00
2026-11-13 11:10:30 +08:00
2026-11-13 16:15:16 +08:00
2026-11-13 16:15:16 +08:00
2026-11-13 16:15:16 +08:00
2026-11-12 12:06:46 +08:00
2026-11-13 17:58:59 +08:00