Clean up failed TransferEngine instances during P2PStore retries

Summary

P2PStore.__init__ retries transfer-engine initialization up to 8 times, but it creates a new TransferEngine() on every attempt. If a failed engine initialization leaves sockets, ports, file descriptors, or shared-memory state behind, each retry can leak resources or keep the same conflict alive.

Why this matters

The retry loop is meant to recover from startup port conflicts. If failed TransferEngine instances hold resources until GC or process exit, retrying with a fresh object may make the failure more persistent and can leave unnecessary native resources around.

Suggested investigation

• Check the mooncake-transfer-engine lifecycle API for an explicit close/destroy/shutdown method.
• Confirm whether a failed initialize() call owns any resources that must be released.
• Either reuse one TransferEngine across retries or explicitly clean up the failed instance before the next attempt.
• Add a focused test with a fake engine if a cleanup seam can be introduced without importing mooncake in CPU-only tests.

Start at P2PStore.init and trace its retry loop, then check the mooncake-transfer-engine lifecycle API for cleanup after failed initialize() calls. Use a fake engine if a CPU-only test seam can be introduced. Done means retries no longer retain failed engine resources and a focused test verifies the cleanup or reuse behavior.