orchestrator: the fault-recovery test expects at least one pass after the heartbeat (#555)

[nathancrtr]

Closes #555.

What this changes and why

One assertion in several-engines.test.ts changes. The fault-recovery test now expects the heartbeat to run at least one pass instead of exactly one. It failed once on main after #550 merged (expected 2 to be 1, run 36442605821, first attempt); the re-run passed.

When alpha recovers, its pass dispatches. The commits that makes, or the fake dispatcher settling, can queue a refs or completion pass while the heartbeat pass is still running. The loop starts that queued pass before the heartbeat's trigger returns, so the count reads 2. That second pass is correct behaviour, so the assertion was the wrong part.

The looser assertion still pins the retry. Every pass before the heartbeat backed off, so any count above zero came from the heartbeat.

Evidence

• Race forced (the wrapper fires a refs trigger inside the first recovered pass): the old assertion fails with expected 2 to be 1, the CI message; the new one passes.
• Mutation: make the heartbeat back off like the other triggers in triggers.ts (!isBoundary(why) → why !== 'startup'): the new assertion fails with expected 0 to be greater than or equal to 1. Restored.
• several-engines.test.ts 20 times in a row: 20 passed (68 tests each).
• The whole orchestrator/test suite 5 times in a row: 5 passed (515 passed, 2 skipped each).
• npm run typecheck and npm run lint: exit 0.

Checklist

• gateline render --check passes (rendered agents current)
• No vendor or model names in roles/ or contracts/
• packages/framework still takes no runtime dependencies
• Tests pass: the orchestrator suite locally (above); the full npm test is left to CI, since only this test file changed
• No retro-edits to completed runs under runs/