test(runtime-host): observe pre-factory drain over handshake, not registration file

[Astro-Han]

Summary

The drain requested before factory completion begins drain before recovery exactly once test in packages/runtime-host was flaky and failed the test job on main after #1658 landed (run 30544963454), even though #1658 only touches packages/headless and the runtime-host code was identical between the PR and main runs. The flaky test was introduced in #1359.

The flake came from asserting on the registration file mid-flight. requestDrain() flips the in-memory #state to 'draining' synchronously, but persisting that to the registration file is the async writeHostRegistration I/O in #closeResources, and #start() had already persisted 'recovering' before entering the composition factory. The test's fixed sleep(50) bet that I/O landed within 50ms, which lost on loaded CI runners and read back stale 'recovering' (AssertionError: + 'recovering' - 'draining').

That assertion tested a non-contract. No production caller reads HostRegistration.state; clients learn draining from the handshake (#admitHandshake returns kind: 'draining' from #shutdownRequested), and connectResolvedRuntimeHost reads the registration only for rootId, hostEpoch, and the endpoint. The invariant the test name claims, "begins drain before recovery exactly once", is already proven by the final lifecycle array ['factory-return', 'begin-drain', 'recover', 'close'] with begin-drain counted once, and the in-memory draining state is covered elsewhere (candidate.host.state === 'draining').

Drop the sleep(50), the readHostRegistration call, and the registration.state === 'draining' assertion. The test still verifies, while the factory is suspended, that startup has not settled, that no lifecycle event has fired, and that the host still holds the interactive root owner lock, then checks the full lifecycle ordering after release.

A handshake-based replacement was tried first but also raced: #closeResources calls server.close() right after the registration write, so on loaded CI the socket stops accepting before connectRuntimeHost connects, returning unavailable instead of draining (the first push of this PR). Polling the registration file would fix the timing too, but it keeps testing a field no caller reads, so deleting the assertion is the smaller and more correct fix.

Refs #1658 (main CI failure, not a regression from that PR).

Verification

• npm --workspace @maka/runtime-host run build then node --test dist/__tests__/host-kernel.test.js: 30/30 pass
• All runtime-host tests in parallel, node --test --test-concurrency=4 "dist/__tests__/*.test.js": 364/364 pass
• 40 consecutive runs of the targeted test: 40/40 pass (no sleep or I/O left in the assertion path)
• Reproduced the original flake by injecting a 300ms writeHostRegistration delay: the old sleep(50) form fails with + 'recovering' - 'draining'; the deleted form has no file read to race
• Reproduced the failed handshake approach by delaying the connect 200ms: returns unavailable, matching the first push's CI failure
• npm run format:check, npm run lint, npm run typecheck: clean