fix(tests): deterministically gate the DoHealthChecksAsync reentrancy-guard test

[jeremydmiller]

What

CoreTests.Runtime.Agents.leader_election_self_visibility_tests.reentrancy_guard_prevents_concurrent_DoHealthChecksAsync failed in full-suite net10.0 runs with:

Expected to receive exactly 1 call matching: TryAttainLeadershipLockAsync(any CancellationToken)
Actually received 2 matching calls

while passing in isolation and in full-suite net9.0 runs.

Diagnosis

The reentrancy guard in NodeAgentController.DoHealthChecksAsync (from #2999) was never broken — the race was in the test's synchronization. The test parked the winning call inside the guard with await Task.Yield() in the mocked TryAttainLeadershipLockAsync, assuming the other nine competing calls would launch before the winner resumed. Task.Yield() gives no such guarantee: the yielded continuation lands on an xUnit sync-context worker thread and can finish the entire mocked election path — releasing the guard — before the test thread even starts the second call. That second call then legitimately re-enters the guard and acquires the lock a second time. A warm thread pool plus net10.0 scheduling made the window reliable in full-suite runs; cold isolated runs and net9.0 timing happened to stay on the lucky side.

Fix (test only)

Park the winner on TaskCompletionSources instead — the mock signals entered and awaits release — so the guard is provably held while the nine competitors run. The test now also asserts:

• competitors bounce off the guard with the AgentCommands.Empty singleton and never reach TryAttainLeadershipLockAsync
• the winner still elects leadership after release
• new coverage: the finally block frees the guard — a subsequent health check goes all the way through again

Verification

• Full CoreTests suite, net10.0 (the previously failing configuration): 1860 passed, 0 failed
• Test class in isolation: green on net10.0 and net9.0

🤖 Generated with Claude Code