Migrates the active transaction window from old logs to newly recruited log configuration.

Solves the critical data migration challenge of transferring the current window of committed transactions to known-good storage. Since recovery must read old logs anyway to verify what's recoverable, it duplicates that data to new logs rather than trusting potentially corrupted or failing storage. This ensures storage servers can continue processing from reliable storage.

Migration Strategy (Consistent Hashing): With consistent hashing, shard→log mapping is computed at runtime. Each new log receives the full list of survivors (old logs that were locked) and can pull transactions from any of them. The log's personalized transaction stream is reconstructed by pulling from survivors and filtering by shard index.

For initial recovery (no old logs), each new log is initialized with an empty transaction stream at version zero.

Service Access: All log services (old and new) are locked by this point in recovery, so the phase simply retrieves their PIDs from the service_pids map using Map.fetch! to enforce that all required services must be available.

Data Integrity: Only copies committed transactions within the established version vector (the active window), discarding uncommitted transactions that lack durability guarantees. Maintains transaction ordering and ensures storage servers can continue processing seamlessly in the new configuration.

Stalls with detailed failure information if log copying fails due to service issues. However, immediately halts with error if any log reports :newer_epoch_exists (this director has been superseded). Transitions to sequencer startup with complete migration.