fix(batch): use blockhash(block.number - 1) in _tryBlockAndAggregate

[lau90eth]

Summary

_tryBlockAndAggregate was calling blockhash(block.number), which
always returns bytes32(0) on mainnet EVM — the current block's hash
is not yet available during execution.

The correct value is blockhash(block.number - 1), consistent with
the existing getLastBlockHash() implementation in the same contract.

Root Cause

blockhash(N) returns 0 when N >= block.number. The existing tests
passed only because Foundry's test environment populates block hashes
differently from production EVM.

Fix

• Multicall3From._tryBlockAndAggregate: block.number → block.number - 1
• Updated tests to assert the correct value

Testing

forge test --match-path contracts/test/batch/Multicall3From.t.sol

29 tests passed, 0 failed.

[ZhiyuCircle]

lau90eth Thanks for the contribution! We're intentionally replicating Multicall3's behavior here, see https://github.com/mds1/multicall3/blob/main/src/Multicall3.sol#L79-L83. We'd like to keep the bug preserved to match expectations from other chains where Multicall3 is deployed.

[lau90eth]

Got it, thanks for the context! Didn't realize this was intentionally matching the upstream Multicall3 behavior. Closing this PR.

[osr21]

Confirmed from dApp testing: blockhash(block.number) returns bytes32(0) on Arc Testnet exactly as on mainnet EVM — the current block's hash isn't available during execution. We hit this when building a nonce-uniqueness helper that tried to seed a hash from the current block.

blockhash(block.number - 1) gives the expected non-zero value. Good fix.