WT-18433 Report the block header fields on a read checksum mismatch

[etienneptl]

When a block read fails its checksum, __wti_block_read_off() reported the two checksums and dumped the raw block, but never the fields already sitting in the header it had just read — in particular it never compared the header's disk_size against the size in the address cookie. That one comparison separates the right block with damaged bytes (bit rot; the existing flip scan is the right next step) from a structurally valid block of a different size at that offset (a stale, misdirected or lost read/write, where flip analysis is meaningless). Both previously printed the same line, so telling them apart took a manual hex decode of a dump that can contain user data.

Adds a separate __wt_errx_id(session, 1843300, ...) line carrying the decoded headers and a greppable verdict:

HEADER_SIZE_MISMATCH: block header disk_size 7168, requested size 3584, flags 0x1;
page header mem_size 3505, write_gen 2, entries 66, type 7 (WT_PAGE_ROW_LEAF), flags 0x4, version 1

On the block header checksum branch, where no scan runs today, the stored checksum is also tested for being one bit off the expected one — no scan can find that flip, because a scan assumes the stored checksum is the one the write path computed.

Diagnostic output only: the read still fails and still panics.

[github-actions]

Thanks for creating a pull request! Please answer the questions below by editing this comment — completing this upfront typically speeds up the review process.

Checklist before requesting a review

• I have performed a self-review of my code.
• I can point to specific tests that would catch regressions of this change, or I've documented why existing test coverage is sufficient.
• I have made corresponding changes to the documentation, or no documentation change is needed.

What makes this change safe?

Help reviewers focus their attention by answering these questions:

• Data format compatibility: Does this change modify the format of WT data or metadata? If so, does this change support non-disruptive upgrade of older systems?
• Test coverage: Which specific tests validate your change? (Name the test files/functions that would fail if your change were reverted)
• Risk assessment: What functionality could break if this change has bugs? How thoroughly have you tested edge cases?
• Review focus: What aspects would you want a teammate to double-check?

Type of change made in this PR

• Functional change
• Test-only change
• Refactor-only change
• Other non-functional change

References:

• Risk level guide
• Testing frameworks

[wiredtiger-prbot]

Woohoo, the code changed in this PR is pretty well tested! 🎉

Metric (for added/changed code)	Coverage
Line coverage	86% (18/21)
Branch coverage	92% (12/13)

• Code change report
• Code coverage report (catch2)
• Code coverage report (full)