test(runtime-host): remove flaky registration state assertion

[M4n5ter]

English

Summary

Remove the flaky assertion that treated an asynchronously persisted registration snapshot as a stable ready state. The bounded-election test still verifies the real process-level SIGSTOP scenario and the stable outcome: an existing Host that misses the election deadline does not launch a second Candidate.

The root cause is that retryConnect() proves an accepted handshake, not that the registration file has reached ready; recovering is a valid last observed snapshot under CI load.

Fixes #3570

Verification

• npm run build:test — passed
• npm --workspace @maka/runtime-host test — 1101 passed, 0 failed
• Targeted bounded-election test — 3 consecutive isolated passes
• npx biome check packages/runtime-host/src/__tests__/host-kernel.test.ts — passed
• npm run lint — passed
• npm run format:check — passed
• npm run typecheck — passed

Root cause

The removed assertion tested an asynchronous registration-file intermediate state rather than a stable product contract. The diagnostic continues to report the last observed registration snapshot; no production behavior or diagnostic serialization changed.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex contributed the bounded investigation, one-line test change, validation, and this PR description. The commit retains a Generated-by: Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No — the change removes only a non-contract diagnostic-state assertion; product behavior is unchanged

简体中文

概要

删除把异步持久化的 registration 快照当作稳定 ready 状态的脆弱断言。bounded-election 测试仍然保留真实的进程级 SIGSTOP 场景，并继续验证稳定结果：已有 Host 未在 election deadline 内响应时，不会启动第二个 Candidate。

根因是 retryConnect() 只能证明 handshake 已被接受，不能证明 registration 文件已经达到 ready；在 CI 负载下，recovering 是合法的最后观测快照。

Fixes #3570

验证

• npm run build:test：通过
• npm --workspace @maka/runtime-host test：1101 通过，0 失败
• 目标 bounded-election 测试：连续 3 次独立运行通过
• npx biome check packages/runtime-host/src/__tests__/host-kernel.test.ts：通过
• npm run lint：通过
• npm run format:check：通过
• npm run typecheck：通过

根因

被删除的断言测试的是异步 registration 文件中间态，而不是稳定的产品契约。diagnostic 仍然报告最后一次观测到的 registration 快照；没有改变生产行为或 diagnostic 序列化。

AI 使用

• 没有生成式工具作出实质贡献
• 生成式工具作出了实质贡献

工具与范围：OpenAI Codex 参与了有界调查、单行测试修改、验证和本 PR 描述编写。提交保留了 Generated-by: Codex trailer。

检查清单

• 测试覆盖了本次变更，且没有本变更时测试会失败
• 本地 lint、format、typecheck 和受影响测试套件均已通过

本 PR 是否改变行为？

• 是 — 已在上方 Summary 中说明
• 否 — 本次仅删除非契约性的 diagnostic state 断言；产品行为未改变

[Astro-Han]

Review at exact head 339ed48e2ddfa2484efaf962098d14ac9162122f.

APPROVE. One deleted line, and it's the right one.

-        assert.equal(result.diagnostic.lastRegistration?.state, 'ready');

The assertion was over-specified: the test exists to prove that a handshake which exhausts its deadline does not launch a Candidate, and launchCount === 0 is what actually establishes that. recovering is a legitimate registration state at that point, so pinning state to 'ready' made a valid outcome fail. The surrounding guards that carry the test's real meaning — pid, deadlineElapsed, sawEndpointConnected, and launchCount === 0 — are all untouched, so this narrows the assertion without weakening what the test proves.

Independent corroboration that this is a live problem, not a theoretical one: I hit this exact failure today while gating an unrelated PR. #3533 (which touches only packages/runtime/src/ai-sdk-backend.ts) went red on ✖ bounded election does not launch a Candidate after handshake exhausts the deadline inside ✖ non-serving Runtime Host kernel — this test. There is no reachable path from ai-sdk-backend.ts to Runtime Host election, and a re-run on the same head passed. So the flake cost two CI re-runs and a round of "is this red mine?" analysis on a PR that had nothing to do with it.

That is the argument for landing this quickly: a false red doesn't just waste a re-run, it taxes every reviewer who has to first disprove that the failure is theirs. Reported as reproducing 72/100 green, 28/100 red, always with the same recovering vs ready shape.

Deleting a wrong assertion rather than adding a retry, a wait, or a tolerance is the right shape of fix — nothing new to maintain, and the test's actual contract is unchanged.

Verification: exact-head test is completed/success; mergeable is true; the diff is exactly this one line with no other file touched.