triedb/pathdb: add validation for binary.Uvarint in index block operations

[777genius]

Summary

This PR adds missing error checking for binary.Uvarint calls in history_index_block.go to prevent potential infinite loops and crashes when processing corrupted index block data.

Problem

Missing validation in four locations can lead to serious issues:

1. Line 179 (readGreaterThan): Ignores n return value when decoding restart item
2. Line 203 (readGreaterThan loop): No n <= 0 check - CRITICAL infinite loop risk
3. Line 223 (readGreaterThan): Ignores n return value via binary search
4. Line 303 (scanSection loop): No n <= 0 check - CRITICAL infinite loop risk

When binary.Uvarint returns n <= 0, it indicates:

• n == 0: Buffer too small (incomplete varint)
• n < 0: Value overflow (> 64 bits)

Without checks, loops can:

• Run infinitely when n == 0 (pos += 0)
• Access invalid memory when n < 0 (negative offset)
• Silently use garbage values

Solution

Added validation following the existing pattern from lines 169-172:

item, n := binary.Uvarint(data)
if n <= 0 {
    return 0, fmt.Errorf("failed to decode...")
}

For scanSection, used silent break to avoid breaking the internal API.

Testing

Added comprehensive tests:

• TestBlockReaderCorruptedVarint: Tests all three readGreaterThan code paths
• TestBlockWriterCorruptedVarint: Tests scanSection graceful handling
• All existing tests pass (17s runtime)

Context

This follows recent similar fixes in the module:

• d2a5dba: "triedb/pathdb: fix 32-bit integer overflow in history trienode decoder"
• 11c0fb9: "triedb/pathdb: fix index out of range panic in decodeSingle"

[rjl493456442]

We're not interested in reviewing PRs generated by AI.

While some of them might be valid, it's unfair that AI-generated PRs can be created endlessly, while maintainers have to spend significant effort ensuring all the changes are correct and safe.