Stabilize flaky JournalManagerTest.missingVolumePageHandling

[vharseko]

Problem

JournalManagerTest.missingVolumePageHandling is flaky. It creates two volumes, writes non-transactional data, closes, deletes the volume files, restarts, and immediately asserts that startup generated missing-volume alerts:

_persistit = new Persistit(_config);
final AlertMonitor am = _persistit.getAlertMonitor();
assertTrue("Startup with missing volumes should have generated alerts",
        am.getHistory(AlertMonitor.MISSING_VOLUME_CATEGORY) != null);

The MISSING_VOLUME alert is posted by JournalManager.writeForCopy when the journal copier copies a page back to a now-deleted volume (VolumeNotFoundException). For the non-transactional pages this test writes, that copy-back is not part of the synchronous recovery in initialize() — it runs on the background JOURNAL_COPIER thread. So the assertion immediately after new Persistit(_config) races the copier: on a slow/loaded runner no alert has been posted yet and getHistory(...) returns null:

java.lang.AssertionError: Startup with missing volumes should have generated alerts
    at com.persistit.JournalManagerTest.missingVolumePageHandling(JournalManagerTest.java:481)

Observed on build-maven (macos-latest, 26); passes on the other 9 build jobs in the same run. (The sibling missingVolumeTransactionHandling* tests are not affected — their alert comes from synchronous transaction replay during recovery, not the background copier.)

Fix

Force the copy-back with copyBackPages() before the assertion, so the alert is generated deterministically instead of relying on the background copier having already run. ignoreMissingVolumes is still false at that point, so writeForCopy retains the missing-volume pages (it only drops them once ignore is set); the later ignoreMissingVolumes-behavior check (alertCount1 == alertCount2) is therefore unaffected.

Not caused by this PR's parent change

Unrelated to the PR it was blocking (#236, remove useless null checks): its only persistit change is in Persistit.crash() (dropping proven-non-null checks), not the startup/alert path.

Verification

• missingVolumePageHandling 6/6 green (including the ignoreMissingVolumes count check, confirming the pages are retained).
• Full JournalManagerTest class: 13/13.
• Root cause is precisely identified (alert originates in background copy-back, not synchronous recovery), so this is a deterministic fix rather than a best-effort one.