Tests: pin the pruning threshold deterministically, not end-to-end

[mgravell]

Follow-up to #3197, which fixed one flaw in NodeAbsentFromTopologyIsPrunedAfterThreeGenerations - it asserted discovery synchronously with ConnectAsync returning. The failure then moved one line down, to Assert.Contains(doomed, ...) after two generations, still failing about one two-core run in four.

Why

The primitive counts elapsed generations, not observed absences:

internal int OnMissingFromTopology(int generation)
{
    if (AbsentSinceGeneration < 0) { AbsentSinceGeneration = generation; return 1; }
    return generation - AbsentSinceGeneration + 1;
}

So any topology application advances it. A test that applies two generations and then asserts "not pruned yet" is really asserting that nothing else applied one - which it does not control. Hence fast machine passes, two-core runner fails.

I tried suppressing the heartbeat first, on the theory that a background pass was the culprit; it did not fix it, so the assertion is the problem rather than any particular background path.

The split

• AbsenceIsCountedAsGenerationsElapsed drives the counter directly with explicit generation numbers - deterministic, no connection timing involved. It also documents the elapsed-versus-observed distinction, including that a two-generation gap counts as two, which is precisely what an end-to-end test cannot control.
• NodeAbsentFromTopologyIsEventuallyPruned keeps what it can honestly own: an absent, idle, cluster-discovered node is eventually pruned. Bounded loop, so a regression fails rather than hangs.

Verification

taskset -c 0,1 with -c Release /p:CI=true (two cores is what a runner has): 6 clean whole-suite runs, against roughly 1 in 4 failing before.

No library change. The product behaviour is fine and arguably intended - three generations elapsed is three generations elapsed, whoever applied them. If we ever want "three observed absences" instead, that is a deliberate change to the primitive and its own PR.

Note in passing: the same two-core setup keeps turning up unrelated pre-existing flakes of the same family (assert-before-ready) - ScriptingTests.SimpleRawScriptEvaluate and ConnectionFailureErrorsTests.SocketFailureError. Not touched here; worth a separate sweep.