persistit: settle MVCC state at the end of Persistit.initialize()

[vharseko]

Problem

Fixes #264.

After a crash/restart, Volume.getTree(name, false) (and step-based MVCC visibility checks generally) can return a stale answer until background maintenance happens to run. Recovery itself completes synchronously inside Persistit.initialize(), but two maintenance tasks are asynchronous after it:

• the TransactionIndex active-transaction-cache updater thread;
• CleanupManager's pruneTimelyResources(), which fires no earlier than 1 second after startup (MINIMUM_MAINTENANCE_INTERVAL_NS guard: start() sets _lastMaintenance = now, and poll() skips maintenance until the interval elapses).

Until those run, residual tree-version state from before the crash can leak into step-based visibility — e.g. a tree created at transaction step 1 is reported visible at step 0. A fresh ActiveTransactionCache has _ceiling = 0, so hasConcurrentTransaction() returns true for everything until the first recompute(), keeping residual versions alive; and recovery's DefaultRollbackListener.removeTree is a TODO no-op while endTransaction marks the aborted status with setMvvCount(0), so tree-lifecycle residue of uncommitted transactions survives recovery and waits for timer-driven pruning. An application calling Volume.getTree(name, false) shortly after initialize() has no way to know it must wait for internal maintenance timers.

This surfaced as the intermittent CI failure of TreeTransactionalLifetimeTest.createRemoveByStep (see #260 for the test-side settle workaround and #257 for the review discussion that raised the core-level question).

Fix

At the end of initialize(), after pruneObsoleteTransactions() and before the background managers start, settle the recovered MVCC state synchronously:

_transactionIndex.updateActiveTransactionCache();
pruneTimelyResources();

The order matters: pruning consults the active-transaction cache. Both calls are idempotent (the CleanupManager performs the same work on its timer), and the cost is bounded — one ATC recompute (no application transactions exist yet at this point) plus one pass over the timely resources touched during recovery. copyBackPages() already uses the same synchronous idiom before checkpointing.

A deeper follow-up candidate noted in #264: implementing the DefaultRollbackListener.removeTree TODO so rollback replay prunes tree-lifecycle residue itself, instead of relying on later background pruning.

Verification

All green locally (macOS, JDK 21):

• TreeTransactionalLifetimeTest — 5/5, including createRemoveByStep
• RecoveryTest — 11 run, 1 skipped (skipped before the change as well)
• AccumulatorRecoveryTest — 4/4
• WarmupTest — 2/2