`CapsLibrary.sol#validateBorrowATokenIncreaseLteDebtTokenDecrease` uses wrong source of `borrowAToken` total supply rendering validation ineffective which allows anyone to bypass cap limit by deposit via `multicall`
Audit: 2024-06-size-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/Multicall.sol#L26-L46


# Vulnerability details

## Impact
- Validation for cap limit violoations in `multicall` is ineffective thus allowing anyone to bypass the deposit cap limit.  

## Description
`Deposit.sol#executeDeposit` checks that a deposited borrow token (USDC) does not exceed the total cap limit.  
See: [Deposit.sol#L64-L89](https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/actions/Deposit.sol#L64-L89)  
```solidity
    function executeDeposit(State storage state, DepositParams calldata params) public {
        address from = msg.sender;
        uint256 amount = params.amount;
        if (msg.value > 0) {
            // do not trust msg.value (see `Multicall.sol`)
            amount = address(this).balance;
            // slither-disable-next-line arbitrary-send-eth
            state.data.weth.deposit{value: amount}();
            state.data.weth.forceApprove(address(this), amount);
            from = address(this);
        }

        if (params.token == address(state.data.underlyingBorrowToken)) {
            state.depositUnderlyingBorrowTokenToVariablePool(from, params.to, amount);
            // borrow aToken cap is not validated in multicall,
            //   since users must be able to deposit more tokens to repay debt
            if (!state.data.isMulticall) {
                state.validateBorrowATokenCap(); <@ the check
            }
        } else {
            state.depositUnderlyingCollateralToken(from, params.to, amount);
        }

        emit Events.Deposit(params.token, params.to, amount);
    }
```
The check is in `CapsLibrary.sol#validateBorrowATokenCap`.  
It explicitly checks taht the `totalSupply` of a borrow token does not exceed config limit.  
See: [CapsLibrary.sol#L52-L58](https://github.com/code-423n4/2024-06-size/blob/main/src/libraries/CapsLibrary.sol#L52-L58)  
```solidity
    function validateBorrowATokenCap(State storage state) external view {
        if (state.data.borrowAToken.totalSupply() > state.riskConfig.borrowATokenCap) {
            revert Errors.BORROW_ATOKEN_CAP_EXCEEDED(
                state.riskConfig.borrowATokenCap, state.data.borrowAToken.totalSupply()
            );
        }
    }
```

However, after an audit with Spearbit, a concern was raised that cap limit mechanism can prevent users from repaying their debt since they are unable to deposit the amount exceeding total cap limit.  

See [2024-05-30-Spearbit-draft.pdf](https://github.com/code-423n4/2024-06-size/blob/main/audits/2024-05-30-Spearbit-draft.pdf)  
Page 19 / Issue 6.7  

Therefore, another mechanism is introduced in the `Multicall` library to allow users to deposit more than the cap limit and repay their debt. Note that it should allow users to deposit beyond the cap *if and only if* they are using that amount to repay their debt.  

Size enforces this by waiving the deposit cap limit if the deposit function is called via mul