Fix storage range issue during snapsync

[matkt]

PR description

Besu currently has a problem where, if it receives all storage slots at once without an accompanying proof, it correctly sets the end of the range to 0xFFF...FFFF. However, if all storage and a proof are received simultaneously, the logic mistakenly treats the end of the range as the last slot received rather than the expected end of the range. This discrepancy results in incomplete persistence of storage trie nodes.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[siladu]

Not sure how feasible it would be but would love to get an automated test around this. I think it should go in the next release regardless as it has passed a lot of manual sync testing #7620 (comment) so is a clear improvement

[matkt]

added a new tests and also modified the AccountHealingTrackingTest class in order to verify and match the new behavior

[siladu]

LGTM!

[siladu]

@matkt worth a changelog?

[matkt]

@matkt worth a changelog?

don't think it is needed for this one