VirtualDataSource methods related to compaction look redundant

`VirtualDataSource` interface has two methods related to compactions:

* void enableBackgroundCompaction();
* void stopAndDisableBackgroundCompaction();

These methods are used during reconnects to control if compaction should be running or not for the original virtual map and for its reconnect copy. Note, however, that at the MerkleDb (or rather `MerkleDbDataSourceBuilder`) level, compactions are already stopped, when a data source is copied. It means, compactions are managed from two different layers, VirtualMap and MerkleDb, and one of them seems redundant.

If possible, these two methods should be dropped from the interface, so MerkleDb manages data source compactions automatically. If this is not possible for whatever reason, start/stop compaction calls should be removed from MerkleDb / MerkleDbDataSourceBuilder code, assuming compactions are managed from VirtualMap end.

Trace the compaction control between the VirtualDataSource interface, VirtualMap reconnect handling, and MerkleDbDataSourceBuilder. Compare where compactions are stopped during data-source copying and determine which layer should own that lifecycle. Done means one consistent owner remains and the redundant methods or calls are removed without leaving conflicting management paths.

Written by the indexing model from the issue text.