node: reject trailing bytes in stored blocks #35517

<!-- Pull requests without a rationale and clear improvement may be closed immediately. -->

This makes BlockManager::ReadBlock() fail if a stored block record contains trailing bytes after a complete serialized block.

Previously, ReadBlock() deserialized from the byte span returned by ReadRawBlock() but did not check whether the SpanReader consumed all bytes. If the stored record length was larger than the serialized block, the extra bytes were ignored and the block could still be returned as valid.

The change keeps the existing deserialization path, then checks that the reader is empty after reading the block.

The unit test writes the mainnet genesis block to a block file, updates the record length to include 8 extra bytes, confirms ReadRawBlock() sees the larger record, and checks that ReadBlock() rejects it.

Tested with:

cmake -S /private/tmp/bitcoin-core-block-trailing-junk-pr -B /private/tmp/bitcoin-core-block-trailing-junk-pr-build -DBUILD_TESTS=ON -DBUILD_BENCH=OFF -DBUILD_GUI=OFF -DENABLE_WALLET=ON -DBUILD_WALLET_TOOL=OFF -DENABLE_IPC=OFF -DWITH_ZMQ=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build /private/tmp/bitcoin-core-block-trailing-junk-pr-build --target test_bitcoin -j"$(sysctl -n hw.ncpu)"
/private/tmp/bitcoin-core-block-trailing-junk-pr-build/bin/test_bitcoin --run_test=blockmanager_tests

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35517.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Why should this be checked?

Because ReadRawBlock() reads the full byte count stored in the block-file record.

If those bytes deserialize to a valid CBlock but leave extra bytes unused, the record is malformed. Today ReadBlock() silently ignores those leftover bytes and then validates only the deserialized prefix.

This check makes ReadBlock() reject that malformed record instead of treating it as a successful block read. It should not affect valid blocks, because valid block records are fully consumed by TX_WITH_WITNESS(block).

Without a broader motivation and context, this is ai slop