Vulnerability: _makePayment is logically inconsistent with how lien stack is managed causing payments to multiple liens to fail
Severity: medium

Description:
`_makePayment(uint256, uint256)` looping logic is inconsistent with how `_deleteLienPosition` manages the lien stack. `_makePayment` loops from 0 to `openLiens.length` but `_deleteLienPosition` (called when a lien is fully paid off) actively compresses the lien stack. When a payment pays off multiple liens the compressing effect causes an array OOB error towards the end of the loop.\\n```\\nfunction _makePayment(uint256 collateralId, uint256 totalCapitalAvailable)\\n  internal\\n{\\n  uint256[] memory openLiens = liens[collateralId];\\n  uint256 paymentAmount = totalCapitalAvailable;\\n  for (uint256 i = 0; i < openLiens.length; ++i) {\\n    uint256 capitalSpent = _payment(\\n      collateralId,\\n      uint8(i),\\n      paymentAmount,\\n      address(msg.sender)\\n    );\\n    paymentAmount -= capitalSpent;\\n  }\\n}\\n```\\n\\n`LienToken.sol#_makePayment(uint256, uint256)` loops from 0 to `openLiens.Length`. This loop attempts to make a payment to each lien calling `_payment` with the current index of the loop.\\n```\\nfunction _deleteLienPosition(uint256 collateralId, uint256 position) public {\\n  uint256[] storage stack = liens[collateralId];\\n  require(position < stack.length, "index out of bounds");\\n\\n  emit RemoveLien(\\n    stack[position],\\n    lienData[stack[position]].collateralId,\\n    lienData[stack[position]].position\\n  );\\n  for (uint256 i = position; i < stack.length - 1; i++) {\\n    stack[i] = stack[i + 1];\\n  }\\n  stack.pop();\\n}\\n```\\n\\n`LienToken.sol#_deleteLienPosition` is called on liens when they are fully paid off. The most interesting portion of the function is how the lien is removed from the stack. We can see that all liens above the lien in question are slid down the stack and the top is popped. This has the effect of reducing the total length of the array. This is where the logical inconsistency is. If the first lien is paid off, it will be removed and the formerly second lien will now occupy it's index. So then when `_payment` is called in the next loop with the next index it won't reference the second lien since the second lien is now in the first lien index.\\nAssuming there are 2 liens on some collateral. `liens[0].amount = 100` and `liens[1].amount = 50`. A user wants to pay off their entire lien balance so they call `_makePayment(uint256, uint256)` with an amount of 150. On the first loop it calls `_payment` with an index of 0. This pays off `liens[0]`. `_deleteLienPosition` is called with index of 0 removing `liens[0]`. Because of the sliding logic in `_deleteLienPosition` `lien[1]` has now slid into the `lien[0]` position. On the second loop it calls `_payment` with an index of 1. When it tries to grab the data for the lien at that index it will revert due to OOB error because the array no long contains an index of 1.

Impact:
Large payment are impossible and user must manually pay off each liens separately

Recommended mitigation:
Payment logic inside of `AuctionHouse.sol` works. `_makePayment` should be changed to mimic that logic.