Refactor: Centralize signature ordering logic in FLRP transaction builders

[mohd-kashif]

Refactor: Centralize Signature Ordering Logic in FLRP Transaction Builders

Summary

This PR centralizes the signature ordering and AddressMap creation logic in FLRP transaction builders to match avaxp's architecture pattern. This eliminates ~200+ lines of duplicated code across ImportInPTxBuilder, ImportInCTxBuilder, and ExportInPTxBuilder.

Problem

FLRP had duplicated signature ordering logic scattered across each builder:

• Each builder implemented its own addressesIndex-based credential ordering logic
• AddressMap creation was duplicated across multiple methods (initBuilder, buildFlareTransaction, createInputs, etc.)
• Inconsistent with avaxp's centralized approach in AtomicTransactionBuilder
• Maintenance burden: changes required updates in multiple places

Solution

Introduced two centralized helper methods in AtomicTransactionBuilder:

1. createCredentialForUtxo() - Creates credentials with dynamic ordering based on UTXO address positions
2. createAddressMapForUtxo() - Creates AddressMaps matching credential order

All builders now use these centralized methods, ensuring consistent behavior across all transaction types.

Changes

New Centralized Methods:

• AtomicTransactionBuilder.createCredentialForUtxo() - Handles credential creation with UTXO-based ordering
• AtomicTransactionBuilder.createAddressMapForUtxo() - Handles AddressMap creation matching credential order

Refactored Builders:

• ImportInPTxBuilder - Updated initBuilder() and buildFlareTransaction() to use centralized methods
• ImportInCTxBuilder - Updated initBuilder() and buildFlareTransaction() to use centralized methods
• ExportInPTxBuilder - Updated initBuilder() and buildFlareTransaction() to use centralized methods

Technical Details

The signature ordering logic uses addressesIndex to determine the order of addresses in UTXOs:

• If addressesIndex[bitgoIndex] < addressesIndex[firstIndex]: Bitgo signature comes first (slot 0)
• Otherwise: User/recovery signature comes first (slot 0)

This ensures AddressMaps match credential order, preventing signature index mismatches.

Related

• Fixes AddressMap mismatch issues for C-chain import transactions
• Aligns FLRP implementation with avaxp's proven architecture
• Part of ongoing effort to improve code consistency across coin implementations