db/seg, db/seg/patricia: fix fuzz harness defects

[AskAlexSharov]

Three fuzz harnesses fixed, two defect classes, found by running gosentry (Trail of Bits' LibAFL-backed fork of the Go toolchain) against our fuzz targets.

db/seg FuzzCompress and FuzzDecompressMatch — uint8 overflow in the chunk size. pos[i] is a byte, so pos[i]*10 is uint8 arithmetic and wraps for pos[i] >= 26; the int() conversion was applied to the already-truncated value. Both harnesses only ever produced wrapped chunk sizes.

db/seg/patricia FuzzLongestMatch — nondeterministic input. The key list was filled from a Go map and then indexed to build the match data, so the same input built a different test string on every run. gosentry measured edges_stability at 59%: coverage feedback was partly noise, and a crash saved to the corpus would not have replayed. Sorting the list takes it to 100%.

target	before	after
FuzzLongestMatch stability	59%	100%
FuzzCompress with overflow detection	panics in ~1s	120,828 execs clean
FuzzDecompressMatch with overflow detection	panics at exec 100	fixed, same defect

Test-only changes; no production code touched.

Other findings from the same run, not included here

• execution/rlp.(*Stream).List reports a uint8-addition overflow under deep list nesting. The reported operation does not match the source line (limit - size on []uint64), so the attribution is likely displaced by inlining — unresolved, needs a look.
• ecrecover.Run and recoverPlain both wrap on v - 27, but a wrapped value can only land in 229–255 and TransactionSignatureIsValid accepts only 0 or 1 — benign.
• swarEdge, bitutil.Select64 and murmur3 wrap by design (SWAR / hash mixing) — benign.
• Fuzz_ProcessUpdates_ArbitraryUpdateCount2 calls hph.Process once per key over a growing trie (quadratic) and types keysCount as uint16, so the average input asks for ~32k keys; it manages ~82 executions in 38s.
• execution/vm.codeBitmap (analysis.go:50) and common/bitutil.Select (select.go:96) wrap by design — SWAR has-zero-byte tests, same family as swarEdge.
• Truncation detection (-truncationdetect=true) is unusable as-is: it fires within the first 1–4 executions of nearly every target — sais.freq_, math.ReadBits, rlp/decode.go:1164, hex_patricia_hashed.go:704. Go narrows integers constantly by design, so it needs a large suppression pass before it yields signal.
• The eliasfano32 targets pad every input to 32KB, holding them at ~60 exec/s. Making the padding fuzzer-controlled gives 2.7–3.7x, but it changes the fuzz signature and invalidates the 8 committed corpus entries, so it needs a corpus migration and is left out of this PR.
• Race and goroutine-leak passes were clean across parallel_compress, parallel commitment and txpool parsing.