Log segment header when archiver instantiation fails

[teor2345]

We had a report of archiver errors on a timekeeper:

I noticed a timekeeper in an endless restart loop and always throwing this panic
archival-node-1 | 2025-02-07T17:05:49.143589Z INFO Consensus: sc_consensus_subspace::archiver: Resuming archiver from last archived block last_archived_block_number=2358
archival-node-1 | thread 'tokio-runtime-worker' panicked at /code/crates/sc-consensus-subspace/src/archiver.rs:713:14:
archival-node-1 | Incorrect parameters for archiver: InvalidBlockSmallSize { block_bytes: 874, archived_block_bytes: 1751094 }
archival-node-1 | note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Things i did:

• I switched cores for the timekeeper thread to run on (no luck),
• I then removed the timekeeper flags and tried to start it but no luck.
• I then removed the timekeeper flags and wiped the node and it started.

Looking at the code, there's nowhere that changes the segment header (last archived block) or block data. So this seems like corruption in the segment or block stores due to overclocking. This PR prints the segment header on archiver instantiation errors, to help diagnose similar errors in future.

This PR also changes an incorrect (but harmless) BlockNumber type in archiver instantiation errors to u32.

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

This is fine, but I suspect one of the historical reasons it was panicking is that function didn't return an error, but now it does, so might be a good thing to return it from here as well (in a simpler form, while using error!() macro to print last_segment_header).

[teor2345]

Alright, this is ready for review again