Vulnerability: totalLend isn't updated on liquidation, leading to permanently inflated value
Severity: medium

Description:
`bank.totalLend` tracks the total amount that has been lent of a given token, but it does not account for tokens that are withdrawn when a position is liquidated. As a result, the value will become overstated, leading to inaccurate data on the pool.\\nWhen a user lends a token to the Compound fork, the bank for that token increases its `totalLend` parameter:\\n```\\nbank.totalLend += amount;\\n```\\n\\nSimilarly, this value is decreased when the amount is withdrawn.\\nIn the event that a position is liquidated, the `underlyingAmount` and `underlyingVaultShare` for the user are decreased based on the amount that will be transferred to the liquidator.\\n```\\nuint256 liqSize = (pos.collateralSize * share) / oldShare;\\nuint256 uTokenSize = (pos.underlyingAmount * share) / oldShare;\\nuint256 uVaultShare = (pos.underlyingVaultShare * share) / oldShare;\\n\\npos.collateralSize -= liqSize;\\npos.underlyingAmount -= uTokenSize;\\npos.underlyingVaultShare -= uVaultShare;\\n```\\n\\nHowever, the liquidator doesn't receive those shares "inside the system". Instead, they receive the softVault tokens that can be claimed directly for the underlying asset by calling `withdraw()`, which simply redeems the underlying tokens from the Compound fork and sends them to the user.\\n```\\nfunction withdraw(uint256 shareAmount)\\n    external\\n    override\\n    nonReentrant\\n    returns (uint256 withdrawAmount)\\n{\\n    if (shareAmount == 0) revert ZERO_AMOUNT();\\n\\n    _burn(msg.sender, shareAmount);\\n\\n    uint256 uBalanceBefore = uToken.balanceOf(address(this));\\n    if (cToken.redeem(shareAmount) != 0) revert REDEEM_FAILED(shareAmount);\\n    uint256 uBalanceAfter = uToken.balanceOf(address(this));\\n\\n    withdrawAmount = uBalanceAfter - uBalanceBefore;\\n    // Cut withdraw fee if it is in withdrawVaultFee Window (2 months)\\n    if (\\n        block.timestamp <\\n        config.withdrawVaultFeeWindowStartTime() +\\n            config.withdrawVaultFeeWindow()\\n    ) {\\n        uint256 fee = (withdrawAmount * config.withdrawVaultFee()) /\\n            DENOMINATOR;\\n        uToken.safeTransfer(config.treasury(), fee);\\n        withdrawAmount -= fee;\\n    }\\n    uToken.safeTransfer(msg.sender, withdrawAmount);\\n\\n    emit Withdrawn(msg.sender, withdrawAmount, shareAmount);\\n}\\n```\\n\\nNowhere in this process is `bank.totalLend` updated. As a result, each time there is a liquidation of size X, `bank.totalLend` will move X higher relative to the correct value. Slowly, over time, this value will begin to dramatically misrepresent the accurate amount that has been lent.\\nWhile there is no material exploit based on this inaccuracy at the moment, this is a core piece of data in the protocol, and it's inaccuracy could lead to major issues down the road.\\nFurthermore, it will impact immediate user behavior, as the Blueberry devs have explained "we use that [value] to help us display TVL with subgraph", which will deceive and confuse users.

Impact:
A core metric of the protocol will be permanently inaccurate, giving users incorrect data to make their assessments on and potentially causing more severe issues down the road.

Recommended mitigation:
Issue totalLend isn't updated on liquidation, leading to permanently inflated value\\nFor the best accuracy, updating `bank.totalLend` should happen from the `withdraw()` function in `SoftVault.sol` instead of from the core `BlueberryBank.sol` contract.\\nAlternatively, you could add an update to `bank.totalLend` in the `liquidate()` function, which might temporarily underrepresent the total lent before the liquidator withdrew the funds, but would end up being accurate over the long run.