Fix superblock IO error handling and add footer validation

[xiaoxichen]

This change improves superblock error handling and integrity checking:

• Fail fast on IO errors during superblock read instead of treating them as fresh/unformatted disks
• Add footer superblock validation for HDD devices to detect corruption
• Check header and footer write errors independently to prevent silent failures
• Add comprehensive unit tests covering all error scenarios

Changes:

• read_first_block(): Now throws std::system_error on IO errors instead of returning garbage data
• write_super_block(): Separately validates header and footer writes with independent error checking
• sanity_check(): New method that validates footer consistency on HDD devices by comparing header and footer superblocks using full memcmp
• Added 6 unit tests covering IO errors, corruption detection, and footer validation scenarios

Use release assert instead of exceptions for superblock IO errors

Per review feedback, replace exception throws with HS_REL_ASSERT for all superblock IO errors to ensure immediate crash on failure:

• read_first_block(): Use HS_REL_ASSERT instead of throwing std::system_error
• sanity_check(): Use HS_REL_ASSERT for header/footer read errors and mismatch
• Update tests from ASSERT_THROW to ASSERT_DEATH to verify crash behavior

[xiaoxichen]

@JacksonYao287 this is a replacement PR for #866

could you please take a review

[JacksonYao287]

when we first boot and format a single device in homestore

  uint32_t DeviceManager::format_single_device(dev_info& dinfo) {

      auto pdev_id = populate_pdev_info(dinfo, attr, m_first_blk_hdr.system_uuid,
                                        fblk->this_pdev_hdr);

      auto pdev = std::make_unique< PhysicalDev >(dinfo, oflags, fblk->this_pdev_hdr);

     // here, after pdev is created , we then write the superblk.
      pdev->write_super_block(buf, sb_size, hs_super_blk::first_block_offset());
  }

and we will do sanity_check in the constructor of pdev

 PhysicalDev::PhysicalDev(const dev_info& dinfo, int oflags,
                            const pdev_info_header& pinfo) {
      // ...
      m_super_blk_in_footer = m_pdev_info.mirror_super_block; // HDD → true

      // sanity_check()  here is called before super_blk is written.
      sanity_check();
  }

if we get brand new HDD, that`s fine since all the data(footer and header) we read is 0.

however, if we reuse some HDD from the decommissioned clusters, there probably some legacy data on them. so when we read header and footer and then do memcmp, it is probably crash at line 174 since they are probably different legacy data.

[JacksonYao287]

LGTM, only this concerning case

[xiaoxichen]

nice catch

[xiaoxichen]

@JacksonYao287 comment addressed