tapfreighter: fix bug with burns not being recognized

This fixes the main part of the flake that caused burns to sometimes not
be recognized correctly.
Because we now also use the allocation code to create virtual packets,
we need to apply the same ordering of inputs to the selected commitments
before choosing the first input that the burn key is derived from.
Otherwise it can happen that the actual first input in the allocated
virtual transaction is another one and the resulting burn key isn't
recognized correctly.

Author: guggero

tapfreighter/wallet.go

@@ -5,6 +5,7 @@ import (
 	"context"
 	"errors"
 	"fmt"
+	"slices"
 	"time"
 
 	"github.com/btcsuite/btcd/blockchain"
@@ -525,7 +526,13 @@ func (f *AssetWallet) FundBurn(ctx context.Context,
 	}
 
 	// Now that we know what inputs we're going to spend, we know that by
-	// definition, we use the first input's info as the burn's PrevID.
+	// definition, we use the first input's info as the burn's PrevID. But
+	// to know which input will actually be assigned as the first input in
+	// the allocated virtual packet, we first apply the same sorting that
+	// the allocation code will also apply.
+	slices.SortFunc(activeAssets, func(a, b *AnchoredCommitment) int {
+		return tapsend.AssetSortForInputs(*a.Asset, *b.Asset)
+	})
 	firstInput := activeAssets[0]
 	firstPrevID := asset.PrevID{
 		OutPoint: firstInput.AnchorPoint,