[claravanstaden]

A static loop-in deposit can stay mapped in deposits.swap_hash to a swap that didn't spend it:

What happened	Mapped to	Should be
Swap A isn't paid before its payment deadline, so the client cancels its invoice and gives the deposits back. Swap B selects them, then the htlc tx A already signed confirms, and A sweeps them back through the htlc timeout path	B	A

Impact: this needs the server to publish A's htlc tx after A's payment deadline, and other swaps to select all of A's deposits in between, so it's rare. When it happens, the deposits are listed under the other swaps, and A's on-chain cost (#1248) is missing. A still sweeps its htlc timeout path: after a restart it has no deposits mapped to it, so it uses the deposits it signed its htlc tx for.

Fixes:

• From now on: when A's htlc confirms and A locks the deposits for its timeout sweep, it maps them back to itself. After a restart A first adds the deposits B selected, in the order A signed them. A deposit B already completed with stays with B.
• Existing deposits: a one-time startup repair (MigrateRepairHtlcTimeoutDepositSwapHash) maps each deposit on the htlc timeout path to the swap whose htlc tx spent it. If lnd can't list the wallet txs, loopd still starts and the repair runs again at the next start.

Both only remap if the tx that spent the deposits spends exactly the deposits the swap signed its htlc tx for: the confirmed tx at runtime, the confirmed lnd wallet tx in the repair, which must also pay to the swap's htlc, since two swaps can select the same deposits. The htlc confirmation is registered by script, so a swap's state alone isn't proof. If it can't tell, the deposit stays as it is.

Not covered:

• If other swaps took only some of A's deposits, the rest are back in Deposited when A's htlc tx spends them, and the deposit manager drops them from its active deposits. A then can't lock any of its deposits, retries forever and never sweeps, as on master, so the funds stay in A's htlc until someone sweeps them by hand. A restart doesn't help. Separate follow-up.
• Looped-in deposits that the old migration linked to a failed swap: staticaddr: repair the swap hashes of looped-in deposits #1253.
• Another tx paying to the htlc script still locks the deposits, as on master: separate follow-up.

Tests

TestMonitorInvoiceAndHtlcTxRemapsReclaimedDeposits runs the takeover with the real store (it fails on master) and checks that another tx paying to the htlc script doesn't move the deposits. TestMonitorInvoiceAndHtlcTxRemapsAfterLegacyFallback runs it through the legacy confirmation fallback with a deposit manager that hands out store copies, like the real one. TestMonitorInvoiceAndHtlcTxMapsOnlyLockedDeposits, TestMonitorInvoiceAndHtlcTxRetriesFailedMapping and TestMonitorInvoiceAndHtlcTxNilDeposit cover deposits B completed with, already locked deposits, a failed mapping and a nil deposit. TestRepairHtlcTimeoutDepositSwapHash covers the repair, including a swap still sweeping, another tx paying to the htlc script, an unconfirmed conflicting tx, a spending tx the wallet doesn't know, two swaps that selected the same deposit, unmapped deposits, and the on-chain cost before and after. TestRepairHtlcTimeoutDepositSwapHashWalletError checks that a failed wallet listing doesn't stop loopd and that the repair runs again. TestMonitorInvoiceAndHtlcTxAddsDepositsAfterRestart covers loopd stopping between locking and mapping, with the missing deposit signed first and last, and checks the deposits are in signed order.

Pull Request Checklist

• Add an entry to docs/release-notes/release-notes-next.md, or apply the
  no-changelog label (required by CI)

[litbot-9000]

@bhandras: review reminder
@hieblmi: review reminder