Provide way to rebuild offsets file for slab files

Provide way to rebuild offsets file for slab files; compare timestamps and trigger automatically

Summary

The offsets file associated with each slab file is critical for efficiently locating and accessing chunk data. However, if the offsets file is lost, corrupted, or out-of-sync with its corresponding slab, we currently have no automated way to detect or regenerate it.

We should add support to:

1. Automatically detect stale or missing offsets files by comparing file timestamps or size/checksum checks
2. Rebuild the offsets file from the corresponding slab if necessary
3. Integrate this logic into archive validation, verification, or startup routines

Goals

• Ensure archives remain usable even if offsets files are missing or invalid
• Prevent silent errors or performance degradation due to desynchronized slab/index pairs
• Improve robustness and self-healing capabilities

Tasks

• Define a method to compare timestamps (e.g., slab mtime > offsets mtime)
• Add logic to scan slab files and regenerate offsets file when:
  • Offsets file is missing
  • Offsets file is older than the slab
  • Offsets file is malformed or unreadable or fails checksum checks
• Add logging to indicate when an automatic rebuild occurs
• Add a CLI command (e.g., blk-archive rebuild-offsets) for manual recovery
• Include checks in verify and/or restore paths to trigger rebuilds as needed
• Write test cases covering scenarios:
  • Missing offsets
  • Out-of-date offsets
  • Corrupt offsets
• Document behavior and limitations

Considerations

• Avoid unnecessary rebuilds when offsets are valid
• Warn the user if rebuild fails or results in mismatched metadata
• Ensure performance is acceptable for large slabs during scanning
• Could optionally store a checksum or slab UUID in offsets for validation