test(runtime-host): stabilize bounded-election registration-state assertion

[M4n5ter]

Problem

The Runtime Host test bounded election does not launch a Candidate after handshake exhausts the deadline is flaky after #3454 added an assertion that the final election diagnostic must report:

lastRegistration.state === "ready"

In #3557 CI attempt 1, the test failed with recovering instead of ready:

https://github.com/apache/maka/actions/runs/32626785176/job/97163223187

The failed Runtime Host step passed unchanged on attempt 2. The same failure was also reproduced by building the exact current origin/main in an isolated worktree and running only this test.

Cause

The fixture calls retryConnect(), closes that connection, and immediately suspends the Candidate with SIGSTOP. retryConnect() establishes that the Host accepts a connection; it does not establish that the registration file has already advanced from recovering to ready.

The diagnostic is therefore truthfully preserving the last registration snapshot it observed, while the test asserts a stronger precondition that its setup never established.

This is the same general class of test fragility addressed by #1660, where an assertion on an asynchronously persisted HostRegistration.state was removed after loaded CI observed an earlier valid state.

Scope

This issue is about the test contract, not the product startup behavior tracked by #3279 and not a regression from #3557.

The repair should preserve the bounded election diagnostic coverage introduced by #3454. It should either establish the exact ready-state precondition before suspending the Candidate, if that state is material to the scenario, or stop pinning the diagnostic to a mutable registration state that the scenario does not require.

Runtime election behavior should not be changed merely to satisfy the test.

Acceptance criteria

• The test deterministically proves that no Candidate is launched after the election deadline is exhausted
• The diagnostic assertions cover stable facts established by the fixture
• Repeated isolated runs pass without timing sleeps or widened deadlines
• The product behavior and diagnostic schema introduced by test(runtime-host): attribute Windows startup stalls #3454 remain unchanged

Relationships

• Assertion introduced by test(runtime-host): attribute Windows startup stalls #3454
• Historical registration-state flake precedent: test(runtime-host): observe pre-factory drain over handshake, not registration file #1660
• Product startup context, separate from this test issue: runtime-host: intermittent 'stopped responding during startup' after a Windows upgrade over an existing profile #3279
• First observed here on feat(runtime-host): add managed Host retirement #3557, which does not modify the election path