[Enhancement] Support an absolute persistent data directory

Summary

Allow operators to configure an explicit absolute directory for all persistent IPFS node data.

Details

The current storeFolder setting is always joined to the operating-system home directory in src/store.ts. It selects a folder below the user's home but does not provide a clear, validated way to use a dedicated path such as /srv/adamant-ipfs or /mnt/ipfs-data.

Add an optional absolute dataDir setting. When it is absent, preserve the existing ~/<storeFolder> behavior exactly so current installations continue to use the same blockstore, datastore, peer identity, pins, and lifecycle registry.

Changing the resolved data directory to an empty location creates a new peer identity and makes existing content appear missing. The implementation and migration documentation must therefore fail safely and make the selected path explicit.

Checklist

• Add an optional absolute dataDir configuration value
• Preserve storeFolder as the backward-compatible fallback when dataDir is absent
• Reject empty, relative, root, malformed, or non-directory values during startup validation
• Resolve the effective data directory in one reusable helper
• Place blockstore and datastore below the resolved directory
• Log the resolved data directory at startup without exposing sensitive data
• Verify that the directory can be created, opened, and written before starting Helia
• Detect and clearly report a likely accidental switch from a populated legacy directory to an empty data directory
• Document a stop, copy, permissions, verification, and rollback procedure for moving an existing node
• Add tests for the legacy default, an explicit absolute path, invalid paths, and restart persistence

Notes

The broad checklist in #16 marked data-directory configuration as complete, but the current implementation still resolves storeFolder from the user's home directory. This focused issue defines the remaining operational requirement.

The datastore contains the libp2p private key under /pkcs8/self. A correct migration must preserve it together with the blockstore and lifecycle registry, or the process starts as a different peer.

Coordinate the change with the storage paths used by disk-reserve checks, storage metrics, upload admission, replication intake, and garbage collection from #22.

Verification

• Start with no dataDir and confirm that an existing ~/<storeFolder> retains the same Peer ID, pins, registry records, and readable CIDs
• Start with an explicit temporary absolute directory and confirm that blockstore and datastore data survive a restart
• Move a populated test store with the documented procedure and confirm byte-identical retrieval of legacy CIDs
• Confirm disk usage, free-space reserve, upload admission, replication, and garbage collection all inspect the configured filesystem
• Confirm invalid or unsafe paths abort startup with a controlled configuration error
• Exercise the rollback procedure and confirm that the original store remains usable

Coordination with persistent health state

The persistent data directory must also contain the checkpoint and repair-cycle state introduced by #23. Moving only the blockstore and datastore while leaving that operational state behind could reset the freshness watermark, lose the recorded membership or placement version, or make height move backwards after restart.

When dataDir is absent, preserve the existing location of all legacy data and introduce any new checkpoint state without moving current stores. The migration and rollback procedure must treat peer identity, pins, lifecycle registry, repair cursor/cycle evidence, and checkpoint state as one consistency unit.

Additional checklist

• Store checkpoint, repair-cycle, and related operational state below the effective persistent data directory
• Preserve or safely invalidate that state during data-directory migration without allowing a false ready checkpoint

Additional verification

• Move a populated test data directory and confirm peer identity, content, lifecycle records, repair-cycle evidence, and checkpoint monotonicity survive together
• Start with missing or mismatched checkpoint state and confirm the node falls back to starting or stale rather than reporting ready

Start with the current path resolution in src/store.ts, then trace the storage-path integrations noted in #22 and the checkpoint state from #23. Verify how startup validation, persistence, migration, and rollback currently work; done means the effective directory is used consistently, legacy behavior remains intact, unsafe paths fail safely, and the listed restart and migration checks pass.