Enable manifest portability via implicit relative path resolution

[google-labs-jules]

Summary

This PR introduces implicit relative path resolution for manifest files, replacing machine-specific absolute paths with relative paths based on the manifest's location. This ensures that audit trails and integrity checks remain valid when projects are moved between different researchers, environments, or operating systems.

Rationale

Previously, manifests recorded absolute filesystem paths (e.g., /home/user/project/data.set). If a collaborator downloaded that project to C:\Users\Collaborator\Downloads\project, verification would fail because the recorded paths no longer existed.

By using the manifest file's parent directory as an implicit root, we achieve:

• Portability: Projects can be moved anywhere without breaking the audit trail.
• Seamless UX: No manual configuration or CLI flags are required; the system handles resolution automatically.
• Tool Compatibility: External tools like EEGLAB/MATLAB require absolute paths to find sidecar files (like .fdt files). By expanding paths back to absolute strings during the read_manifest phase, we maintain compatibility while keeping the stored representation portable.

Key Changes

• Path Serialization: Implemented _make_manifest_relative in eegprep/cli/core.py. This calculates the delta between the artifact and the manifest location using pathlib.
• Cross-Platform Consistency: Utilized .as_posix() for serialized paths to ensure that manifests generated on Windows (using backslashes) are compatible with Linux/macOS and vice versa.
• Automatic Expansion: Updated the manifest loading API (read_manifest) to recursively resolve relative paths back into absolute paths upon ingestion.
• Serialization Hooks: Injected path conversion logic into write_manifest and write_manifest_file to ensure all output artifacts are processed before being written to disk.

Constraints & Considerations

• Volume Limits: Relative path conversion is only supported for artifacts located on the same volume/drive as the manifest file.
• Integrity Preservation: These changes do not modify the original data files; they only alter how paths are represented in the JSON metadata. Standard SHA-256 integrity checks remain 100% compatible.

Acceptance Criteria Progress

• Manifests saved to disk now contain relative path strings.
• Cross-platform verification (Linux to Windows) is successful.
• Runtime processing functions receive expanded absolute paths.
• Verification correctly fails if file content hashes are modified, regardless of pathing.