test(runtime-host): wait for queued successor before shutdown

[zhiiw]

Summary

• make the queued-followup integration test observe the automatically admitted successor through the canonical session subscription
• wait for that successor root to reach a terminal fact before terminating the Runtime Host
• close the fixture's initial execution-store persistence before releasing its root lease

Root cause

The test asserted the first root's terminal state and then terminated the Host while the queued successor could still be active. On a fast run the successor happened to finish first; on a slower Linux CI run shutdown raced the active root and failed with Runtime Host shutdown did not cleanly close every resource.

The test now observes the successor through the same public subscription surface used by clients and waits for its terminal fact. It does not relax Host shutdown behavior or add retries.

Validation

• npm run build -w @maka/runtime-host
• the original focused scenario now reaches a terminal successor before shutdown
• Windows still reports the existing child.kill('SIGTERM') emulation difference; this PR is intended to validate the original Linux CI failure

This PR intentionally does not address the unrelated Astryx UI/Knip failures currently present on main.

中文说明

改动

• 通过 canonical session subscription 观察 queued follow-up 自动创建的 successor root；
• 等 successor 到达终态后再终止 Runtime Host；
• fixture 初始化时显式关闭 execution-store persistence，再释放 root lease。

根因

旧测试只等待第一轮进入终态，随后在 queued successor 仍可能执行时终止 Host。运行较快时 successor 恰好先结束，运行较慢时 shutdown 会与活跃 root 竞争，Linux CI 因此报 Runtime Host shutdown did not cleanly close every resource。

新测试不放宽 Host 的关闭契约，也不添加重试；它通过生产客户端使用的 subscription surface 证明 successor 已启动并到达终态。

验证

• npm run build -w @maka/runtime-host
• 原始定向场景现在能够在 shutdown 前观察到 successor 终态
• Windows 仍有既有的 child.kill('SIGTERM') 模拟差异；本 PR 由 Linux CI 验证原始失败

本 PR 不处理当前 main 已存在的 Astryx UI/Knip 失败。

[zhiiw]

CI follow-up:

• typecheck: passed
• test: passed, including the runtime-host integration suite that originally failed during successor shutdown
• e2e: still fails in the pre-existing Astryx UI scenarios on the current base; intentionally out of scope for this test-lifecycle PR

The discriminating result is the green test job: waiting for the queued successor's terminal fact removes the original Linux shutdown race without relaxing Host cleanup behavior.

中文说明

CI 跟进结果：

• typecheck：通过；
• test：通过，包含此前在 successor shutdown 阶段失败的 runtime-host integration suite；
• e2e：仍失败于当前基线已有的 Astryx UI 场景，按本 PR 的 test-lifecycle 边界不处理。

关键证据是 test job 已转绿：等待 queued successor 的终态后，原来的 Linux shutdown 竞态消失，同时没有放宽 Host 清理契约。

[Astro-Han]

Thanks for adding this coverage — "wait for the queued successor before shutting down" is a scenario worth having a test for.

I am closing this one. It is 1236 commits behind main, execution-host.test.ts has been through several rounds of change since, and it is currently conflicting. More importantly, the queued successor lifecycle it targets is being rewritten in #3633, so assertions written against the old behaviour may not match the rewritten semantics.

Once #3633 lands, this scenario would be worth re-adding against current main. I have noted the idea and will bring it back up then.

简体中文

谢谢这条补的覆盖——"关机前要等排队的 successor 起来"这个场景确实值得有测试守着。

这条我准备关掉。它比当前 main 落后 1236 个提交，execution-host.test.ts 在这期间已经改过多轮，现在是冲突状态；而且它针对的 queued successor 生命周期正在 #3633 里被重写，这份基于旧行为写的断言不一定还对得上重写后的语义。

建议等 #3633 落地之后，基于当前 main 重新补一条这个场景的测试。这条的思路我会记着，到时候会提醒把它捡回来。