fix(app): LaunchEnd 也清 pending 并记失败原因，补早失败回归测试（M43 r3 两条 P2）

P2-1（本轮新引入的回归）：`pending` 只在 LaunchStarted 清除，但 `launch::start`
的两条早失败出口（build_request 失败 / spawn 失败——没装 Java、版本 JSON 坏就是
这两条）只发 LaunchEnd → pending 永久残留 → `in_flight` 恒真 → 该实例本会话再也
启动不了，磁贴锁在「启动中」。修：LaunchEnd 分支先 `pending.remove`，早失败与
正常收尾都释放。

P2-2（failed 零 insert）：上一轮只在 note 里声称「失败原因进 failed 表」，代码没
落地（唯一 insert 缺失，refresh 的 Failed 分支是死代码，test 6 还靠手动塞表绕过）。
修：LaunchEnd 非 Ok 时 `failed.insert(id, summary)`、Ok 时 remove；refresh_instances
的 Failed 分支从此由真实路径喂数据。

测试（123 → 124，全部走真实入口）：
- 新增 `launch_end_before_launch_started_still_releases_the_instance`：mark_pending
  → handle(LaunchEnd Crashed) → pending 空、in_flight 假、refresh 后磁贴是
  Failed{reason}（同时钉住 P2-1 与 P2-2）。
- test 6 重写：Busy 断言改走 `mark_pending`（start_launch 用的同一入口），Failed
  断言改走 `handle(LaunchEnd Crashed)`，不再手动塞 failed 表。
- 所有测试的数据根加 `TempRoot` Drop 守卫，跑完不留临时目录。

crates/app/src/host/handle.rs

@@ -90,10 +90,19 @@ impl CoreHost {
                 self.send(CoreEvent::InstanceRuntimeChanged { id, runtime });
             }
             HostTask::LaunchEnd(finished) => {
+                // 收尾可能发生在 LaunchStarted 之前（build_request / spawn 失败只发
+                // LaunchEnd）：pending 必须在这里也清掉，否则 in_flight 恒真、该实例
+                // 本会话内再也起不来。
+                self.pending.remove(&finished.id);
                 self.launches.retain(|live| live.instance != finished.id);
                 let runtime = if finished.outcome == LogOutcome::Ok {
+                    self.failed.remove(&finished.id);
                     InstanceRuntime::Idle
                 } else {
+                    // 记住失败原因：随后的 refresh_instances 会重建快照，
+                    // 不记的话磁贴的「失败/重试」外观会被 Idle 盖掉。
+                    self.failed
+                        .insert(finished.id.clone(), finished.summary.clone());
                     InstanceRuntime::Failed {
                         reason: finished.summary.clone(),
                     }