fix: strip leading zero digits from value in eth_estimateGas requests

[dan437]

Explanation

Some RPC nodes strictly parse hex quantities (Go's hexutil) and reject eth_estimateGas requests when the transaction value contains leading zero digits, e.g. 0x00 or 0x0de0b6b3a7640000:

json: cannot unmarshal hex number with leading zero digits into Go struct field TransactionArgs.value of type *hexutil.Big

Dapp libraries commonly pad hex to an even byte length (e.g. ethers v6 toBeHex(0) returns 0x00), so dapp-provided values can hit this on strict chains. When the estimate call fails, the controller silently falls back to a percentage of the block gas limit, which can exceed a chain's per-transaction gas cap and cause every submission to fail.

This change normalizes value in the eth_estimateGas request built by estimateGas():

• Strips leading zero digits from strict hex strings (0x00 → 0x0, 0x0de0b6b3a7640000 → 0xde0b6b3a7640000).
• Keeps the existing nullish default (0x0).
• Leaves non-hex input untouched so it still fails into the fallback path as before.

data is intentionally not touched — it is bytes, not a quantity, so leading zeros are semantic there.

References

• Related to CONF-1740
• Same failure mode as fix: gas limit estimation  #4897, which fixed the gas field by removing computed fields from the estimate request; value cannot be removed, so it is normalized instead

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
Small, localized change to gas-estimate request shaping with explicit tests; no auth or submission-path changes.

Overview
Fixes gas estimation failures on RPC nodes that reject non-canonical hex quantities in eth_estimateGas (e.g. Go hexutil rejecting 0x00 or 0x0de0b6b3a7640000), which often comes from dapp libraries padding value to even byte length.

estimateGas() now runs transaction value through a new normalizeValue helper before the RPC call: nullish still becomes 0x0, strict hex strings lose leading zero digits, and non-hex input is left unchanged so existing error/fallback behavior is preserved. data is unchanged (byte data, not a quantity).

Tests cover the value matrix; the changelog documents the fix.

^{Reviewed by Cursor Bugbot for commit 4f81422. Bugbot is set up for automated code reviews on this repo. Configure here.}