fix: handle edge case when change amount is below minimum capacity

[fghdotio]

When actualInputsCapacity > sumOutputsCapacity but the resulting change amount is below MIN_CAPACITY, we also need to collect additional cells to ensure the change output meets the minimum capacity requirement. This prevents creation of invalid cells with insufficient capacity.

[duanyytop]

Why do you use a while loop? How do you return from the loop?

[duanyytop]

I think if the changeCapacity < MIN_CAPACITY is true, throwing an error is enough for issuers.

[fghdotio]

Initially I mistook txFee for fee rate - I thought the loop ensures sufficient capacity to cover increasing transaction fees as the transaction size grows with each new input from collectInputs. As actualInputsCapacity accumulates in the loop, changeCapacity gradually increases until it either exceeds MIN_CAPACITY for normal exit, or throws CapacityNotEnoughError when available cells are insufficient.

Upon closer inspection after reading your comments, I realize a while loop is unnecessary since txFee is set to a sufficiently large MAX_FEE constant. A simple if statement would be adequate here.

Despite its name, appendIssuerCellToBtcBatchTransferToSign serves as a general fee supplement method in offline mode. Perhaps we should collect additional issuer's cells as inputs to cover tx fee whenever possible, instead of throwing an error. Please let me know your thoughts.

[duanyytop]

1. The MAX_FEE is 0.2CKB, and it is enough for almost transactions.
2. If the issuer's balance is not enough for collecting, the loop does not work.
3. I think you could provide a capacity estimate function for the issuer before collecting cells.

[fghdotio]

Good point! I'll try to implement it later.