The transaction builders (ScriptTransactionBuilder, BlobTransactionBuilder, CreateTransactionBuilder, etc.) include a max_fee_estimation_tolerance field. This field determines the buffer added to the estimated gas cost when calculating the max_fee for a transaction, if a specific max_fee is not already set via TxPolicies. The default value for this tolerance is currently DEFAULT_MAX_FEE_ESTIMATION_TOLERANCE (0.50), defined in packages/fuels-programs/src/lib.rs.

However, high-level APIs that internally use these builders do not provide a direct way to configure this tolerance before building the transaction:

1. Executable::upload_blob: This method creates a BlobTransactionBuilder internally and uses the default tolerance without allowing user configuration.

   // packages/fuels-programs/src/executable.rs L180
   let mut tb = BlobTransactionBuilder::default()
       .with_blob(self.blob())
       .with_max_fee_estimation_tolerance(DEFAULT_MAX_FEE_ESTIMATION_TOLERANCE); // Default used

2. Call Handlers (ScriptCallHandler, ContractCallHandler, etc.): These handlers typically build ScriptTransaction or ContractCall transactions internally. While users can set TxPolicies (potentially including a fixed max_fee), they cannot directly configure the max_fee_estimation_tolerance that the underlying builder will use if fee estimation is performed (i.e., if TxPolicies::max_fee is None).

The current workaround involves obtaining a transaction builder from the configured call handler (e.g., using call_handler.into_builder() or ScriptTransactionBuilder::from(call_handler)) or creating the BlobTransactionBuilder manually. Then, the user must set the desired tolerance on this builder instance using .with_max_fee_estimation_tolerance(new_tolerance), and finally proceed to finalize and send the transaction using the builder directly. This bypasses the convenience of the higher-level methods like .call() or Executable::upload_blob.

This lack of direct configuration forces users to drop to lower-level builder manipulation when they encounter situations where the default tolerance (50%) is insufficient, leading to "InvalidMaxFee" transaction failures.

Requested Change:

Introduce convenient methods on the relevant high-level APIs to allow configuration of the max_fee_estimation_tolerance used by the underlying transaction builders: