Fix finalization RPC methods to use hex serialization for U64 values

[Copilot]

Overview

This PR fixes finalization RPC methods to serialize U64 values as hex strings instead of decimal numbers, making them consistent with other RPC methods in the codebase.

Problem

Finalization RPC methods were returning U64 values as decimal numbers:

{
  "proof": { ... },
  "l1Height": 12345,
  "lastL2Height": 7899324
}

This was inconsistent with other RPC methods that use hex strings for numeric values, and made the API less developer-friendly for blockchain applications where hex representation is standard.

Solution

1. Custom U64 Hex Serialization Module

Added utils::u64_hex module that:

• Serializes U64 as hex strings with 0x prefix (e.g., "0x3039")
• Accepts both "0x3039" and "3039" formats for deserialization
• Maintains full compatibility with existing U64 internal representation

2. Updated Finalization RPC Response Types

Applied hex serialization to key finalization fields:

• LastVerifiedBatchProofResponse.l1_height
• SequencerCommitmentResponse.l2_end_block_number
• BatchProofOutputRpcResponse.last_l2_height
• LightClientProofOutputRpcResponse.last_l2_height
• Other height/number fields in finalization-related responses

3. HexU64 Wrapper Type

Created strongly-typed HexU64 wrapper for RPC methods that return U64 directly:

• getLastScannedL1Height → returns HexU64
• getHeadL2BlockHeight → returns HexU64
• getVerifiedBatchProofsBySlotHeight → accepts HexU64 parameter
• Other height/number related methods

4. Updated Components

• RPC Server: Updated to handle HexU64 conversions transparently
• Test Client: Modified to work with new HexU64 wrapper types
• Comprehensive Tests: Added serialization/deserialization validation

After

Finalization RPCs now return consistent hex format:

{
  "proof": { ... },
  "l1Height": "0x3039",
  "lastL2Height": "0x789abc"
}

Backward Compatibility

• Internal U64 logic unchanged - only serialization format affected
• Type-safe conversions ensure no runtime errors
• Test client methods transparently handle the new format

Testing

• ✅ Hex serialization works correctly (e.g., 12345 → "0x3039")
• ✅ Deserialization accepts both "0x3039" and "3039" formats
• ✅ Round-trip serialization preserves data integrity
• ✅ Test client methods updated and working

Fixes #2535.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.