Issue 4804: Fix txn compaction recovery leaving entry logs unreclaimed

[void-ptr974]

Fixes #4804

Problem

DefaultEntryLogger.incompleteCompactionLogs() rebuilds txn compaction logs from *.compacted files after a restart. Entry log file names are hex-based, but this recovery path parsed the destination log id from the hex file name and then rebuilt the final .log file name from the numeric id directly.

For example, 1f4.log.78.compacted has destination log id 1f4, which is decimal 500. Recovery should make 1f4.log available, but the old path targeted 500.log.

Impact

For affected log ids, makeAvailable() creates the recovered log under the decimal file name. Later scan/recovery resolves log id 500 through the normal hex file name and looks for 1f4.log.

That mismatch prevents txn compaction recovery from scanning and finalizing the recovered log. The .compacted marker and old source entry log remain on disk, so disk space for that compaction is not reclaimed. Ledger entry contents are not changed.

Fix

Build the recovered final .log file name with logId2HexString(compactionLogId).

Coverage

• Recovery creates 1f4.log for log id 500 and does not create 500.log.
• Normal txn compaction still creates the hex-named final log.
• Upgrade case: if an older recovery attempt already left a stale 500.log while the .compacted marker remains, fixed recovery still creates and scans 1f4.log and leaves the unrelated stale file untouched.

Testing

• mvn -pl bookkeeper-server -Dtest=DefaultEntryLogTest#testRecoverCompactedLogUsesHexFinalLogFileName+testRecoverCompactedLogWithStaleDecimalLogFileFromOldRecovery+testNewCompactionLogKeepsHexFinalLogFileName test
• mvn -pl bookkeeper-server -Dtest=DefaultEntryLogTest test