[ZkTracer] fix conversion bytes to int/long

[letypequividelespoubelles]

This PR implements issue(s) #

Checklist

• I wrote new tests for my new core changes.
• I have successfully ran tests, style checker and build against my new changes locally.
• I have informed the team of any breaking changes if there are any.

---

Note

Low Risk
Small, localized conversion changes; behavior only differs for edge cases (oversized inputs/overflow) where callers will now get validation or ArithmeticException.

Overview
Fixes numeric conversion helpers in Conversions to be unsigned-safe and overflow-aware.

bytesToLong now converts via toUnsignedBigInteger().longValueExact() instead of toLong(), and bytesToInt now enforces a 4-byte maximum and uses Math.toIntExact(...toLong()) to fail fast on out-of-range values rather than silently truncating.

^{Written by Cursor Bugbot for commit 1fe826f. This will update automatically on new commits. Configure here.}

[OlivierBBB]

I solved the same issue I think on the 7702 HUB PR by letting LEAD_DELEGATION_BYTES be a long rather than an int. Probably best to use the same approach in both PR's.

[letypequividelespoubelles]

it could work as well. But the issue is that this functiun can be called elsewhere and has to be fixed anyway. And once it's fixed, there is no need to have the leading bytes as long, as it's an (unsigned) int. Or the best would be to have leadingBytes a Bytes of length 4 ...

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

[cursor]

Redundant trimLeadingZeros() call instead of reusing variable

Low Severity

In bytesToInt, the local variable trimmedBytes is computed on line 137 but then line 139 calls bytes.trimLeadingZeros() again instead of using trimmedBytes. This is redundant computation and inconsistent with the pattern in bytesToLong, which correctly reuses its trimmedBytes variable. The conversion on line 139 likely intended to be trimmedBytes.toLong().

 

[cursor]

bytesToInt throws for valid 4-byte address fragments

High Severity

The new bytesToInt uses Math.toIntExact(bytes.trimLeadingZeros().toLong()). For 4-byte inputs where the high bit is set (unsigned value > Integer.MAX_VALUE), .toLong() zero-extends to a positive long exceeding int range, causing Math.toIntExact to throw ArithmeticException. The existing caller in RomLex passes operation.byteCode().slice(3, 4) (an Ethereum address high part), which can have any byte value — roughly half of all addresses will crash the tracer.