Stabilize flaky TreeTransactionalLifetimeTest.createRemoveByStep

[vharseko]

Problem

TreeTransactionalLifetimeTest.createRemoveByStep is flaky. Its crash/restart sub-cases reopen Persistit and return without waiting for recovery and timely-resource pruning to settle:

if (crash || restart) {
    _persistit = new Persistit(_config);
    _persistit.initialize();
}

Recovery and the pruning of timely tree resources run asynchronously after initialize(). So the next helper iteration can begin a transaction against not-yet-settled state, and residual tree-version state from the previous iteration's crash/restart leaks into the new transaction's step-based MVCC visibility — a tree created at step 1 becomes visible at step 0:

org.junit.ComparisonFailure: Expected contents at steps
  expected:<0[],1:,2:a=step2,3,4:b=step4>
  but was:<0[:],1:,2:a=step2,3,4:b=step4>
    at com.persistit.TreeTransactionalLifetimeTest.createRemoveByStepHelper(TreeTransactionalLifetimeTest.java:215)

Observed on build-maven (ubuntu-latest, 21); it does not reproduce on macOS (40 local runs green).

Fix

Quiesce the MVCC state after the restart by updating the active-transaction cache and pruning timely resources — the same idiom the sibling tests in this class already use before asserting (updateActiveTransactionCache() + pruneTimelyResources()). The change adds nothing but a settle point; it weakens no assertion (the expected2 check after restart is unaffected — pruning removes only obsolete versions).

Not caused by this PR's parent change

Unrelated to the PR it was blocking (#257, which fixes Bug1017957Test.induceCorruptionByStress): that PR touches only Bug1017957Test.java, a different test.

Verification

• Happy path with the fix: createRemoveByStep 7/7 green; full TreeTransactionalLifetimeTest class 5/5.
• The flake does not reproduce locally (macOS), so the fix is validated by mechanism analysis and happy-path stability; the two settle calls are idempotent no-ops when the state is already quiesced. CI is the real confirmation.

[vharseko]

Closing in favor of #266: it adds the same two calls (updateActiveTransactionCache() + pruneTimelyResources()) at the end of Persistit.initialize(), so the settle happens for every caller — including this test's crash/restart helper — rather than only inside TreeTransactionalLifetimeTest. With #266 merged, the test-side quiesce added here would be redundant.