Fix(wallet): validate absolute fee bump replacements

[Jennycj]

Fixes issue #549

Description

Previously, Wallet::create_tx only checks fee < previous_fee.absolute when bumping a fee with TxBuilder::fee_absolute. This misses out on 2 arms of the FeePolicy::FeeRate arm, causing transactions to be built without error, but then be rejected by BIP125 replacement policy (rule 4: must pay for its own bandwidth at the incremental relay fee; Bitcoin Core additionally requires a higher fee rate than the original).

Wallet::create_tx now:

• Rejects an absolute replacement fee that is less than or equal to the original transaction fee.
• Calculates the replacement’s effective fee rate after coin selection and final transaction weight are known.
• Rejects absolute fee replacements whose fee rate is below the original fee rate plus FeeRate::BROADCAST_MIN.

This ensures that the appropriate fee error is returned when TxBuilder::fee_absolute attempts to build replacement transactions that do not satisfy the required absolute fee and incremental relay fee rules

Notes to the reviewers

The selected fee_policy is retained so absolute-fee replacements can be validated after coin selection. The final transaction weight is used to ensure the replacement fee rate exceeds the original fee rate by the required incremental relay fee.

Appropriate regression tests were added, and the absolute-fee values were updated in tests:

• test_bump_fee_reduce_change
• test_bump_fee_absolute_force_add_input

These fixtures previously passed the absolute-fee-only check but no longer satisfy the final replacement fee-rate requirement.

Changelog notice

Wallet::create_tx enforces a strictly higher replacement fee and validates the final replacement fee rate after coin selection.

Before submitting

• I followed the contribution guidelines
• This PR breaks the existing API

[busayo-OD]

Thanks for working on this! There are a few things around the fee validation logic that I wanted to mention.

[busayo-OD]

This FeeAmount check appears twice consecutively. The duplicate block can be removed.

[Jennycj]

I missed removing this after testing. Good catch!.

[busayo-OD]

This enforces a fee-rate floor (previous_rate + 1 sat/vB) rather than the BIP125 fee requirements. These differ when the replacement's weight changes, so the resulting minimum fee can be either higher or lower than the BIP125 requirement.

[Jennycj]

The current implementation does a fee rate increment. I would go back to work on this.
Thank you!

[busayo-OD]

I’m wondering if this should use the final realized fee instead of the requested fee_amount, since dust handling can add excess to the actual fee.

[Jennycj]

The caller passes the requested fee_amount which will serve as the final realized fee. The check is placed after coin selection, just before the psbt is finalized, so dust handling should already be factored in.

[busayo-OD]

I think there may still be a case where fee_amount differs from the realized fee. I was able to reproduce this with a 720 sat requested fee resulting in a 1,000 sat realized fee due to dust handling. Since fee_amount isn't recomputed after coin selection, the check would still use 720 sat rather than the realized fee.

[Jennycj]

Yeah, this was covered in the updates made in 94f3941